JDE EnterpriseOne Security Best Practices
The standard security mechanism both for World and EnterpriseOne is very complex. End-users need to create security restrictions in the applications to authorize the right users for the right conte
The standard security mechanism both for World and EnterpriseOne is very complex. End-users need to create security restrictions in the applications to authorize the right users for the right content, to ensure data protection policies are enforced etc. These requirements generate a need for making security easier to apply and administer.
This is where ALLOut comes in.
We offer efficient tools to help you reduce the cost and effort of managing security in JDE.
Whilst you get good standard security functionality in E1, it isn’t perfect. And when it comes down to security, you want perfect!
So here is some ALLOut Advice:
Process Based Roles
People move in and out of business and change jobs within them, but the basic process roles (usually) remain constant.
Process based roles work on individual business processes e.g. journal entry – security is assigned (to a role) so that a business process can function in isolation. These Process based roles are then assigned to users who need to perform that business process.
Process roles function best when employing a ‘Closed’ security model
Base your security on allocating these process based roles to users, rather than setting up security user by user. Simple add or remove roles as a user’s job functionality changes.
Open vs. Closed
Open: EnterpriseOne is shipped with no records in the security table meaning that once users are able to access the system they can access and update all programs and data – this is known as an ‘Open’ security model.
Typically, security in an ‘Open’ environment consists of the following:
- Using Menu security – this involves the denial of FastPath and the use of Menu Filtering (FineCut) to hide certain areas of the system. This is not security as form and row exits allow users to access (potentially unsecured) connected programs.
- Using Application and Action Code security to limit access and update ability to critical and sensitive programs – generally applied to *PUBLIC. This is known as a ‘Deny Critical’ strategy
ALLOut does not recommend using an ‘Open’ security model. It is difficult to ensure that the system is totally secure.
In order to achieve compliance, very large data sets are required – this makes reporting and maintenance harder.
Closed (‘Deny All’): the alternative ‘Closed’ strategy is where all objects and update actions are denied from all users by default. The programs and actions required by a user, in order to do their job, are granted back where necessary.
This ‘Closed’ method is the most secure way of operating your business critical ERP system as users must be specifically authorized to transactions. The main issue with this approach is the time taken to find, grant and test all required applications – especially those ‘under the covers’ that are not immediately obvious. Application and Action security is applied at the *PUBLIC level to act as a 'catchall' that denies access to all programs in the system. Specific applications and actions are granted back to those users/roles that require them.
ALLOut recommends using a ‘Deny All’ strategy.
If you need help with your security design project, please contact us and we will put you in touch with one of our valued partners who will be able to assist you.