Risk. Managed. - How to save time and manage security effectively.

It can be a challenge or even an impossible task to manage the many complexities of risk within JD Edwards. When it comes to managing security problems, the biggest question you should ask yourself is, does it really need to take-up this much time in my day? There are three main types of security in JD Edwards:

 

  • Program related – Security that determines what a user can do.
  • Data related – Once in the program, this security will control the records a user can access.
  • System related – Affects menu access, data browser access or who can access fast-paths etc. 

 

Efficient security design and best practice can go a long way!   

 

When it comes to designing your JDE application security, you’ll want to align it with each business process in your business and ensure you have a deep understanding of the processes that are in place. The key is to have 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 duplicate security or the manual task of updating user permissions every time a change needs to be made to their security or access controls. 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, StartOut can help you save 100’s of 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. 

 

Simplify and reduce maintenance time by using inclusive row security. 

 

Row security works by controlling the ability for a user or role to View, Add, Change and Delete 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.  Security in multiple roles can be merged more easily (whether by a program or manually) because where you want to merge 2 sets of access, combining 2 sets of what you are restricted from can result in no access to anything. The key is to approach row security from a perspective of ensuring that uses 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 convert your legacy exclusive row security to inclusive automatically.

 

Layer security and streamline your roles to reduce day-to-day maintenance. 

 

Once you have process-based roles and simplified, inclusive row security in place, you can take advantage of layering your security by having small, process based multiple roles. Indeed, people will come and go from your business but the processes stay the same. With smaller roles that include all the consolidated security details, you can simply add or subtract a role from a user without having to update individual security records every time. 

 

When using multiple roles, you may have 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 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. 

 

Security Quick-Tip: Use ALLOut CombiRoles to automatically and consistently solve sequencer conflicts. It Identifies conflicts for a user and automatically creates “Y” settings that over‐ride the role level security. All this while allowing full visibility to the adjustments and reasons for them. Save you and your team some time and simplify your day-to-day security maintenance. Also, don’t worry about stray security records in your system.  Each time the process is run, it will validate any existing records that were automatically created to see if they are still necessary.

 

Do you want to arrange a demo? Contact hazel.jackson@alloutsecurity.com