Managing security is complex and time-consuming...

Managing security in JD Edwards can be complicated and resource-heavy. There are over 30 different security types in E1 - some of which determine what users can do (program-related), control the records a user can access (data-related), and control how a user moves around JDE with menus or UDOs ( navigation-related). At this point, if you're responsible for maintaining security in your organization, the biggest question you should ask yourself is - "...does it really need to take up this much time in my day?".

Small, process-based roles can go a long way 

When it comes to designing your JDE application security, you’ll want to align it with each of your business processes and ensure a deep understanding of the processes that are in place. The key is to have small process-based roles so you can include all the security details and access that’s needed for that process. Once you’ve set that up, different users across multiple departments that need access to that same process can be assigned the role. You don't need to worry about maintaining the same access in multiple roles or manually managing user-level access each time a change is needed. This allows you to create re-usable building blocks to use in applying security.  While users change responsibilities, the programs used in a process do not. 

Security Quick-Tip: If you’re in the process of re-designing security, ALLOUt StartOut can help you save 100’s hours by giving you a set of pre-defined, best practice roles, menus, and E1 pages. All you have to do is analyze, adjust and upload to JD Edwards. 

When assigning more than one role to a user, you will run into issues where users can’t access certain programs despite having a role that should give them access. This is due to the JDE security hierarchy and is caused by the role sequencer conflicts. When a user signs in, the system first checks the user ID for security, then it checks the roles that the user has, and finally, it checks *PUBLIC. This results in a role with a higher role sequence number having view-only access to an application, preventing a user from performing updates that are granted by another role that has been applied to that user. Use ALLOut CombiRoles to automatically and consistently solve sequencer conflicts. It Identifies conflicts for a user and automatically grants the highest level of access they have been granted by any role.

Reduce maintenance time by using inclusive row security 

Row security works by controlling the ability of a user to interact with data. JD Edwards offers two methods of applying row security, inclusive and exclusive. Exclusive security blocks access to a specified range of values (the Row Security ‘View’ or update flags are set to ‘N’).  All ranges of values outside of the designated range would be available.  Inclusive records grant access to a defined range of values (the Row Security ‘View’ or update flags are set to ‘Y’). When using inclusive, all values outside of the designated range are automatically denied. 

It is best practice to use inclusive row security which is not the default. It is easier to use when viewing and maintaining records because you can see what is available to the role. The key is to approach row security from the perspective of ensuring that users have access to what they need.  Access risk and surprises are eliminated with inclusive row security.  

Security Quick-Tip: Did you know you can save time and free-up resources by using ALLOut SecurityPlus to convert your legacy exclusive row security to inclusive automatically? If you are already benefiting from inclusive security, ALLOut CombiRoles allows you to combine the access from multiple row security roles to simplify giving a user all of the access they need.

Align UDO 'View' Security with your Roles

JDE provides security functionality to allow User Defined Objects to be controlled – this security layer (F00950W) sits on top of the standard application security layer (F00950). 

When it comes to UDO security this primarily depends on the feature, action, and view security. Once someone can create and publish UDOs, you need to establish who you want to be able to see them. This is called 'View Security' and will affect who can view/use shared UDOs created by other users and who can use UDO content in CafeOne UDOs. 

You can simplify the process by ensuring your view security is aligned with your functional security roles! In addition, it can save time and is considered best practice to combine object security and UDO security in the same role so that a user has everything they need when the role gets applied. 

Security Quick-Tip: Use ALLOut SecurityPlus for the enhanced ‘Security Maintenance’ SuperGrid (PAOS0950) that provides easy-to-use functionality to maintain the F00950W table. This will allow you to manage UDO Security (Feature/Content/Action/View) from one screen; alongside existing security. 

If you have any questions, please contact us and a member of the team will be able to assist.