Understanding Multiple Roles

What are the considerations and potential problems that can arise when using multiple roles in Oracle’s JD Edwards (JDE) EnterpriseOne (E1) solution? What are the available solutions within native JDE and how can ALLOut's toolset highlight any multiple role issues and automatically resolve them using the ‘Fix/Merge’ process and/or Super-Roles (CombiRoles)?

Security Hierarchy

The security hierarchy, or the order in which security records are applied, is known as the ‘Net Effect’. This ‘Net Effect’, or actual effective system accepted value, is fundamental to the workings of security in E1. Security can exist at the User, Group/Role and/or *PUBLIC level. When multiple security records exist, the system determines which security records to apply based on the logical hierarchy shown in the graphic below.

The logic applied when verifying security authority for an object is to check the user, then the group/role and then *PUBLIC – taking the first record that is found – if no records are found then authority to an object is given.

Role Sequencer

When a user has two (or more) roles that have different security authority (e.g. update/view) to the same object – E1 needs a way of determining which role takes priority – it uses the ‘Role Sequencer’ to do this.

When a role is created it is assigned a unique role sequence number (F00926) that determines its priority versus other roles – this is only applicable in a multiple roles configuration.

• The role with the higher number in will take precedence over those with a lower number – i.e. in the example screenshot below role ‘01SS’ (50) is higher in ‘priority’ than role ‘01PROC’ (40) in the sequence.
• Drag and drop roles in to the desired sequence – you must click the ‘Set Sequence’ form exit to commit the roles’ sequence to the database. The net effect of the Role Sequencer is that security in some roles may be ignored.

It is almost impossible to prove that users have access to what you think they do – they have been assigned a set of roles but without significant analysis determining which security records are effective is difficult.

Role Sequencer Conflicts

A Role Sequencer ‘Conflict’ can be defined as when an individual user has two (or more) roles, each containing different security and/or Menu Filtering authorities to the same object (and data item when considering Row Security). Example When a user signs on (with Role Chooser *Disabled [*ALL is therefore implicit] or with *ALL Roles and Role Chooser *Enabled) the Role Sequencer will resolve any ‘Conflicts’ that may arise.

Risks

Role Sequencer Conflicts often go unaddressed as they are difficult to diagnose using the standard toolset, without proper testing.

Role Synchronization (Menus & Security)

ALLOut advocates synchronizing Menu Filtering (FineCut) and security for individual roles – this serves several purposes and when it is not implemented can cause issues with using those roles in a multiple roles framework.

Using ALLOut to Identify Multiple Role Issues

It is difficult to know what (if any) multiple role issues exist or that Segregation of Duties Rules have been breached due to Role Sequencer assignments. ALLOut Software provides tools specifically designed to help find any ‘Sequencer Conflicts’ that may arise.  A series of reports ( Role Sequencer Action Code Security Conflict report;  Role Sequencer Row Security Conflict report & “No Wins” Role Sequencer Conflict report) help you to see what issues are evident on your system.

Using ALLOut to Resolve Multiple Role Issues

Super-Roles (Combination Roles)

A ‘Super-Role’ is an ALLOut construct that works on a parent-child basis – it allows multiple ‘Child’ roles (or subroles) to be attached to a ‘Parent’ role (Super-Role or Role List). Each Child-Role is associated with a Super-Role in the same way as a standard role-to-user relationship (F95921). Super-Roles facilitate the following:

Roles within Roles – ALLOut recommends using small process-based roles (sub-roles), which contain both Security and Menu Filtering. These can be combined so that users with access to each process will only see the required menu options and have the correct authorities to the objects that are called.

• Process-based roles can be combined within a Super-Role(s) – this can be used to overcome Oracle’s recommended 30 role limit which can affect some power users.
• An ‘Audit Trail’ can be created to track role assignments – this includes the ability to attachments and notes

Multiple Role Sequencer Conflict Resolution – ‘Yes’ records are written (by the ALLOut Fix/Merge process) to a parent Super-Role when conflicting records exist for multiple roles, attached to the same user. This therefore allows users to continue to do their job where sequencer conflicts would stop them.

• Row Security Accumulation – this includes where two or more roles have conflicting row security ranges to the same data item(s) and table(s) combination. The conflicting ranges are merged, and written to the Super-Role (by the ALLOut Fix/Merge process) – this enables users with that SuperRole to access the ‘accumulated’ data ranges.

Benefits & Limitations

There are practical limits to the number of Child-Roles that should be assigned to a Super-Role – this is due to the maintenance and performance overheads involved.

From an assignment, troubleshooting and reporting standpoint, the number of sub-roles that are applied to a Super-Role should be limited to a manageable amount.

• ALLOut recommends single-figures – any more implies that the roles are too granular.
• Identifying which Super-Role to apply to a user (i.e. which Child-Role(s) is required) – becomes more time-consuming the more Child-Roles that exist.

This can result in a one-to-one user-to-Super-Role relationship which defeats the purpose of using Super-Roles and is the same as using job-based roles.

• Using the Fix/Merge to grant the ‘best access’ (i.e. “Yes wins”) to large numbers of roles, practically means that users may have more access than they require – essentially the same as *ALL “Yes” – this can result in Segregation of Duties breaches.

ALLOut supports Super-Roles with up to 750 child-roles but testing should be carried out to ensure that there are no performance issues. Employing a process-based roles strategy minimizes security maintenance – once a process is tested it very rarely changes. Therefore security management becomes more about role assignment – requesting and then assigning a process (e.g. AP Voucher Entry) to a user is much easier than establishing which program(s) to apply to a user/role and then testing the implications of making these changes.

Using process-based roles & data roles in conjunction with ALLOut’s ‘Fix/Merge’ process has been proven to reduce the time spent managing security.

• Any Role Sequencer Conflicts (including data access overlaps) that may arise are automatically resolved.

ALLOut has several tools available to help design and implement a complete process-based roles strategy from Task View creation (including Menu Filtering) or E1 Pages, through to security (including both program and data types) and preventative Segregation of Duties. ALLOut supports reporting over Super-Roles – this includes both Segregation of Duties Reporting, Security Access Reporting and Audit Access Reporting

ALLOut Super-Roles are the ideal way to convert from legacy Functions & Components