JD Edwards Security Best Practices
Lisa C. Benavides | Associate Application Support Consultant
Each business approaches security differently based on its unique business needs. A small business may have users that require a lot of access but have a limited number of roles since they might only have a couple of people in each department. A large company might have a lot more roles set up since different processes will be assigned to different people. The following setup is what the GSI JD Edwards Security Practice uses as the JD Edwards security best practices security model and one that ensures a company’s system is most secure.
The first step in JD Edwards security best practices is to make sure the company’s system is a closed system. The major difference between a closed system and an open system is how the special role *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 E1 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 a role assigned granting certain access and those roles do not have a *ALL “N” (no) 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.
After *PUBLIC has been set up as 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 the different jobs that users have. For example, an ACCOUNTANT (Staff Accountant type user) role will have all the access an accountant would need to perform their job. 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 grants a lot of access. Job-based role models can be difficult to maintain Segregation of Duties, as well as day to day security maintenance because of the overlapping access between roles and the difficulty in distributing the appropriate access to the users.
Process-based roles are set up based on the company’s individual business processes in the JD Edwards EnterpriseOne Software. This model requires quite a few more roles in the system; however, it is significantly more secure and easier to maintain users’ access with this type of setup. For example, with voucher processing, using a job-based setup, the access needed to complete the voucher process might all be in one role. The issue arises when the entire process needs to be split between multiple users. Meaning, one user needs the ability to enter the voucher, while another user needs the ability to review and approve the voucher. In a process-based role setup, because the business processes are already split up into the separate job roles such as: Voucher Entry, Voucher Review, and Voucher Approval, only the roles that are required by the user to perform their job duties need to be assigned to them. Using 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 to distribute the access to users accordingly. Since there can be 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, the individual processes can be leveraged 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 E1 to filter the menu based on each role. By Finecutting a role, EnterpriseOne 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 certain program, only Finecut preventing them from seeing it on the menu, it is entirely possible for the user to still find their way to that program.
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 security model and/or unaware of your potential security gaps, please don’t hesitate to reach out to the GSI Security 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.
To find about GSI’s products or services including JDE project consulting services, managed services, upgrade services, cloud services, and more, call us at 855-GSI-4ERP or click on CONTACT US to send us a request for more information.
Meet the Author
Lisa Benavides
