JD Edwards: Security Best Practices
Robbie Scott, Solution Consultant – Security and Fraud
Each business is unique and therefore how each business approaches security will be different. A smaller business may set up their security so that users may have a small number of roles with a lot of access since they might only have a couple people in each department. A larger company might have a lot more roles set up since different processes will be assigned to different people. The following setup is what GSI’s JD Edwards Security Practice Team uses as the best practice JDE security model and one that ensures a company’s system is secure.
The first step to this practice is to make sure the company’s system is a closed system. The major difference between an open system and a closed system is how *PUBLIC is set up. In an open system, *PUBLIC will either be set up with a line that explicitly has all Y’s for the *ALL object, or it won’t have a line for *ALL at all. Without a *ALL line, JDE considers *PUBLIC to have open action and application security. This *PUBLIC setup is considered open because a new user just entered into the system will have open access to everything in the system without any roles assigned. Moreover, even if the user has roles assigned granting certain access, and those roles do not have a *ALL “N” record for Application and Action security, the user will inherit full access to all objects in the system.
Oppositely, a closed system must have a line with *ALL “N” for Action and Application security. A new user in a closed system won’t be able to access anything without roles assigned. Further, under this recommended security model, users are only able to access objects that have been explicitly granted to them, either by role or user level.
Once *PUBLIC has been closed, the roles can be set up. There are two popular ways to set up roles; job-based and process-based. Job-based roles are roles that are set up based on different jobs that users have. For example, an ACCOUNTANT (Staff Accountant type user) role will have all the access an accountant would need. Whereas, the ACCOUNTMGR (Accounting Manager/Controller type user) role could have some of the ACCOUNTANT role’s access and would have the managerial access as well. A system with job-based roles will not have a lot of roles to assign to users, but each role will have a lot of access. Job-based role models can be difficult to maintain Segregation of Duties as well as day to day security maintenance. One of the main issues with this model is the overlapping access between roles and the difficulty in distributing the appropriate access to the appropriate users.
Process-based roles are set up based on the company’s individual processes in JDE security. This model presents quite a few more roles in the system. However, it is significantly more secure and easier to maintain users’ access in this type of setup. For example, voucher processing. In a job-based setup, the access needed to complete the voucher process might all be in one role, but that role also has access to Voucher Entry, Voucher Review, and Voucher Approval as well as many more. In a process-based role setup, because everything is already split up into Voucher Entry, Voucher Review, and Voucher Approval roles, only the roles that are needed by the user need to be assigned. The issue arises when the job-based role needs to be split between people. Meaning, one user needs ability to enter the voucher, while another user needs to ability to review/approve the voucher. In a job-based role setup, if the process must be split up, new roles will have to be created and already existing ones will have to be edited. Since there are numerous processes for each job, if each process must be split up, the number of roles being controlled by the security team can quickly become unmanageable. A process-based role setup may need more effort put in up front, but in the long run it will be easier to maintain and ensure your users are accessing only the business processes they need in JDE.
After the business processes are mapped out, you leverage those individual processes to construct a menu that coincides with the new roles. The setup of the menu should follow the separation of the roles. Separating the menu out by department, then by process will allow the users to find the programs they use easily. Note: Only the objects that allow the user to perform the process should be within each role. While designing the menu, each role should also be Finecut. Finecut allows JDE EnterpriseOne security to filter the menu based on each role. By Finecutting a role, JDE limits what that role can see in the menu. Note, Finecut is not a form of security, it is menu filtering only. If there is no line preventing a user from accessing a program, only Finecut preventing them from seeing it on the menu, it is entirely possible for the user to find their way to that program. Doing this will also help if any changes are needed in the future, as each role will only see the folders and programs specific to their access. If new programs are added, they will be added in the folder for the process, and no additional finecut maintenance will be needed.
JDE Security can be set up in multiple ways. While one way may make more sense or ultimately grant your users the access they need, it may not conform to best practices and potentially leave the system, and business, at severe risk of fraudulent behavior. If you have been subject to a failed audit, unsure if you are operating a best practice E1 security model and/or unaware of your potential security gaps, please don’t hesitate to reach out to the GSI’s Security Practice Team. We would be more than happy to assist you in ensuring your security model is set up to best practice standards and the business is safe from potential fraudulent behavior.
Meet the Author