Removing inheritance on position-based security

[Former Member]

We have been using Position-Based Security for 10 years.  A recent audit prompted the thought that maybe we did not want users to automatically inherit roles when they fill a position.  We still want to use Position-Based Security so when users are terminated or change positions, they automatically loose their security roles.  But, we are considering having users 'request' access when the get inherit a position.

Is there a way to limit or remove the inheritance of roles when another user occupies a position that previously had roles assigned?

Thanks in advance,

Penny

[Former Member]

Hi Penny,

In your case, better control methodology seems to be more necessary than any technical 'way'/solution.

What we used to do for one of my previous clients is :-

1. Whenever the IT1001 subtype A008 (Holder of) relationship was end-dated/changed for any position, it was mandatory process to also delimit the roles assigned to that position (via IT1001 subtype B007) except for some standard roles like ESS.

2. The user's acquiring new positon would request for new roles or restoration of their previosuly assigned roles. Earlier access was restored only after concerned approvers validated the roles and their necessity to the new position.

Ofcourse, there is a risk that user's might complain of losing all access if their position is changed without prior notification, so you can also schedule a background job to notify security team for any change in IT1001 subtype A008 (Holder of) relationships based on reports RHCDOC_DISPLAY or RHRHAZ00 atleast once in 24 hours. For activating logging of IT1001 subtype A008 changes, you will need to configure thru' table- T77CDOC_CUST.

These days, with GRC AC - HR triggers, the above scenerio of HR position changes can be easily used to automatically initiate request workflow for access adjustments.

Thanks

Sandipan

[Former Member]

Penny,

On one of my clients that used position-based security, we implemented HR triggers via Access Control 5.3. When a position change action occurred in the HR system, it would automatically generate a GRC request that would include the role that were assigned to the person's position.

The approver would have the option of removing or keeping the roles that were associated with the position.

If GRC is not an option, I've also seen clients that use a hybrid scenario where only ESS/MSS/Common roles are assigned to positions and all other "professional" roles are assigned directly to a user. When a user changes positions, they automatically lose whatever roles that are assigned directly to them and must request whatever roles they need that are consistant with their new position.

Thanks

Malcolm DIllon

[Former Member]

Hi.

Not sure how your SAP security set up really works at your end.

It has been my observation with customers who use the method of indirect role assignment, they assign roles to users based on position, wherein the POSITION ID is unique for every user - hire to retire.

And in case there are new position ids created /assigned to the same user id for any reason, there is a alert which pops up to the user when they login to the system because the system does not permit them to even fill time logs without any relevant/ standard roles assigned to the new position ids generated.

In this case, when this position id expires, roles also expire from SU01 for that user. Though we could trace the roles of previous position ids on PO13.

And this type of indirect role assignment, needs a lot of maintenance too.

Wherein for new assignments, triggers also are required to BASIS team for removal of existing roles from PO13 and assignment of new roles for new job assignments as per requirement.

Regards

indu

[Former Member]

Penny,

With my current client only ESS/MSS based roles are assigned to position and other roles are assigned via SU01 record of the concerned user. If you are client has a GRC 5.3 running active then HR triggers can be set.However,this is valid only if GRC 5.3 is active and mapped to the HR systems.

And both suggestions mentioned before, under usual circumstances should be approved/initiated by the client.

So, effectively and immediately scheduling a background job RHCDOC_DISPLAY should help.