JDE Security Best Practices (Part III): Super Roles

What are Super Roles?  How do I get them?  What do they do for me?

In my last post, I discussed the practice of creating Roles for Business Units and User IDs in Oracle JD Edwards (JDE), which eliminates the need for Business Unit Security to be applied to the User ID directly.  The provided illustrations in the post showed only one level: one Role with Business Units and User IDs in relationship with that Role.

Super Roles are a feature that ALL Out Security provides with their software package that allows you to build a hierarchical structure of Roles within Roles, so to speak.  Below we have Figures 1 and 2.  Figure One is a diagram of a hierarchical structure that is layered on top of the diagram that we showed in the Business Unit Security post:

jde super roles
JDE Business Unit Security

In Figure One the Role for the General Administration Department, AL_GENADM, is the Super Role as is the Role for General Operations, AL_GENOPS.  Both of these Super Roles will contain any Business Unit Security Access that is defined in any of the Roles included in the Super Role.

This means that AL_GENOPS will now provide access for USER4 and USER5 to all of the Business Units that have been assigned to AL_BUSDEV, AL_CORPCOM, and AL_FINANCE–in addition to 10380 and 10385 from AL_ITFACL.  USER1, USER2, and USER3 are still limited to 10380 and 10385.

Once you have the theory of the structure down, you can begin building these from the bottom up in ALL Out Security using the Super Role to Role Relationship application that looks and works just like standard Role Relationships with another process built in to make it all hang together.

In the table below, we have the Roles and the Business Units assigned to those Roles:

RoleBusiness UnitsSuper RoleBuild Sequence
AL_BUSDEV104301
AL_CORPCOM10520, 107202
AL_FINANCE103503
AL_ITFACL10380, 103854
AL_GENOPS1073010430, 10520, 10720, 10350, 10380, 10385, 107305
AL_GENADM1094010430, 10520, 10720, 10350, 10380, 10385, 10730, 109406

The Fix/Merge Process

This process is called the Fix/Merge. What it does in the background is set up the Row Security records in F00950 so that you don’t have to.  So, the result for each of the Super Roles is the Business Units defined in the table in the column Super Role.

Could you do this yourself without ALL Out?  Of course you could if you spent sufficient time planning it out–which needs to be done regardless of the tool–then executing it.  What ALL Out also provides is a way to wipe it all out and start over.  With the change of settings in the Fix/Merge, it will wipe out all of the records written in F00950 for the Super Role definitions and will rebuild them based on the newly defined configuration.

Let’s say that AL_ITFACL no longer reported to AL_GENOPS.  You would go into the Role/Super Role Relationship application and remove AL_ITFACL from the list of Roles for AL_GENOPS and rebuild the Super Role.  There are a couple of tricks to this though.  The Business Unit 10730 that was assigned to AL_GENOPS manually will also be gone and need to be re-added.  Then you must go through the same steps for AL_GENADM.  Again, this could be done manually by a sufficiently-trained and dedicated Security Officer.

I also recommend that you build and/or rebuild your Super Roles from the bottom up.  In that way, the Super Roles will contain all of the Business Units in the Roles beneath them without constantly rebuilding your Super Roles.   The same rule pertains to any additional Business Units that you might add to the Roles.  Let’s say that AL_BUSDEV gets an additional Business Unit, 10830.  The Fix/Merge must be re-run for AL_BUSDEV, then AL_GENOPS, and lastly, AL_GENADM.

READ PART ONE
READ PART TWO
By | 2017-03-28T15:20:42+00:00 October 10, 2016|Categories: ERP / JD Edwards|Tags: , |

Receive more posts just like this, right in your inbox!

↓ Sign up for emails with the latest from Smartbridge.

Sign up for emails
Or add this feed URL to your favorite blog reader.