There are many companies that have either an open, or partially open security model and would like nothing more than to implement the best practice model of an all doors closed model for JD Edwards Security. A partially closed security model for JD Edwards can be one in which the application security is restricted, or one in which the Action security is restricted. In both cases however, the job is only half done. So what’s stopping them? In a word, Fear!
Many companies fear the amount of work they think it will take to design, implement, and test a closed security model, or they fear the impact to the business if they don’t get it 100% correct the first time. As Franklin D Roosevelt once said, “The only thing we have to fear, is fear itself”.
Fear not JD Edwards Security practitioners. This month we will explain the process by which you can fully close the door on your security model. To begin, you need to understand the basics of JD Edwards security hierarchy and how the security that you will be applying affects the users that will be validating your hard work.
Security in JDE follows a defined hierarchy. While it may seem like it is random, it has a rigorous structure in place to ensure it is consistently applied. Understanding the rules behind how security is applied is a key to understanding how to identify and resolve issues. Even more importantly, this understanding can help you design security to avoid those issues in the first place.
Security hierarchy is applied in the following sequence:
This is just a high-level view of the security hierarchy. There are additional levels of security at the form and version level that need to be considered depending on how you are building your security.
In all instances of JD Edwards security hierarchy, JDE will always start at step 1. If no entry is found, JDE will move to the next step. Once an entry is found, JDE will apply whatever security it has found, and STOP! Even if there are additional records granting different access, JDE will stop at the first record found and apply that security.
With this understanding in place, we move on to understand how we can apply security differently in the Production environment than we do in the Prototype environment. Many people will implement complex solutions to what can be a very simple solution. JDE gives us the ability to assign security by environment simply by assigning only limited environments. This means I can create a role and only assign the PY environment. When I do this, the user that has this role, will only have the security from this role applied when they login to the PY environment. This is still only part of the equation. As you identify gaps in your application security, you will need to grant that access back to individual roles. Understand that in a security model that is open for Application security, your roles already have access to run any program that you have not already restricted. Adding these grant back records should be reviewed, but will not impact the access your users already have.
Now, on to the fun part, closing the door on your JD Edwards security! For now, we will assume we are working with a security model where the Action security has been locked down to Inquiry only and we will be restricting the Application security. To begin, we need to create a new role that will contain the new security settings to get us to a fully closed state. Let’s call the role “CLOSED”. Using this approach will allow you to migrate users to a closed model in whatever way works best for you including individually, by department, or by location. In this new role, you will need to enter the lockdown setting as shown below:
| User/Role | Object | Run | Install |
| CLOSED | *ALL | N | N |
This setting will restrict users to only those programs where you have entered a Run=Y record, and there are a LOT of them! What do you need to grant access to? There are many programs that are obvious, like Submit Jobs to be able to run a UBE (P98305W), but there are more that are needed, to actually submit the UBE like the printer selection screen (P986162). In addition, you should plan on adding all of the search and select applications that are called from many different places in the system These applications cannot update data, so there is no risk to allow them for all users. This will also include things like the Delete Confirmation Message Box that pops up when you try to delete anything (P98MB01 & P98MB02). There are many different lists of the objects that will need to be granted back, but you should expect to be adding 600 or more lines of grant back access to the programs. Beyond the programs that need to be granted to all users, you will need to grant specific programs back to each role. In many cases, I have seen roles that have Action security records entered for programs but do not have any Application security records. The next step is to go through and add the missing Application records to the existing roles. While this does affect Production, there is no impact as your Application Security is already in an open state.
There are a couple ways of finding and adding all the required application security. The first is trial and error with a LOT of testing (Believe me, it is as tedious as it sounds!). Second is to use a security tool to help identify the form and row exits for each program. Many programs will have large numbers of form and row exits. For example, Sales Order Entry has 69 Form and Row exit options available. This is the main reason we strongly recommend a third-party tool, like ALLOut Security, to streamline the process of identifying and granting access to all those hidden programs.
Once you have granted back the programs that are needed within each role, and you have created the lockdown role, you can assign the lockdown role to users in PY to test and validate. If you run into issues, you can always remove the lock down role to get the user back to their previous state in a matter of minutes. Once everything has been tested in PY, you can then apply the role to users in PD (just add the PD environments to the lockdown role). Just as you did during testing, you can easily remove the lockdown role for a single user if they experience any issues and time does not allow you to troubleshoot the issue immediately. When you have been operating with all users in a closed environment for at least 30 days (we recommend you go through at least 1 period close process) you can migrate the security from the lockdown role to your *PUBLIC setup.
To learn more about implementing a best practices closed door JD Edward security model, contact GSI today.
CONTACT US TODAY
FOR MORE INFORMATION ON JDE 9.2.4 OR GSI'S JD EDWARDS SERVICES