BRM: Prevent deletion of roles with users assigned

[Former Member]

Dear GRC Experts,

when we create a role in BRM and assign users via an access request to this role the deletion of this role in BRM is possible afterwards.

Anyhow I´d like to prevent the deletion of roles with users assigned and force the unassignment of users from this role first.

So deletion should be possible only if no users are assigned currently to that role.

Is that possible?

Many thanks and best regards,

Markus

[Colleen · Accepted solution]

Hi Markus

You would need to enhance the standard if you tried to put a check when the delete button was pressed.

Would it be possible to prototype the following:

• BRM Initiator rule contains a dblookup exists check in BRF+ to see if the role is in the GRAC* user assignment table (I can't think of table of the top of my head)
• If the role exists as at least one entry in the table then you know it has been assigned -> return rule result to send workflow request down a specific path
• If the role does not exist then you can proceed with workflow approval for deletion

For the routing to a specific path you would then need someone to respond to the request by manually triggering ARQ mass role removal requests OR rejecting the BRM role deletion. The BRM role deletion would be put on HOLD until the ARQ is completed. Then it could be approved to continue to the next stage (now meets the scenario or role does not have users assigned).

What I'm unsure of and cannot test... when you delete the role in BRM at what point does it actually delete the role out of the satellite system. I can't remember if that occurs at the end of approval request.

In this suggestion, there is still manual unless there is a way to build logic to automatically create the ARQ.

I'm not sure how you would go about doing this, but could the Role Administrator have a process to check the role and trigger ARQ removal of access before deleting the role? Possibly, even kick of User Access Review for the role to identify all users with it and choose remove as the action.

Regards

Colleen

[Former Member · Accepted solution]

Hi Colleen,

many thanks for your answer.

We do not use the workflow for role maintenance at the moment but directly administer the roles from GRC role maintenance menu.

So I was searching for a way to restrict the deletion of roles there to roles without assignments only.

Thanks for any further advice and best regards,

Markus

[madhusap · Accepted solution]

Hi Markus,

I assume that functionality is not there. But you can restrict through authorization or launchpad customization.

You can control role deletion access through below auth object

Other way is you can customize launchpad and can remove Role maintenance link from unauthorized users.

Regards,

Madhu.

[Colleen · Accepted solution]

Hi Madhu

Removing a link in the launchpad does not prevent them from figuring out the URL and launching directly....unless SICF has authorisation added to it.

The launchpad assist with the look and feel but they do not add the security to them.

Regards

Colleen

[Colleen · Accepted solution]

Hi Markus

To clarify, do you have BRM activated but disabled the approval step in the role methodology?

If that is the case, could you consider switching it on and with the initiator rule if my suggestion is possible, where the role is not assigned then you could send it to a path with no stage (no agent/approval) to trigger automatic approval.

Therefore, only the deleted roles with users would go to an inbox to be actioned.

If this is not what you mean, can you please clarify?

Regards

Colleen

[madhusap · Accepted solution]

Hi Colleen,

Thanks Colleen for clarifying.

Actually my intention was to suggest just don't give access to Launchpad link for Role maintenance (or hide) as well as remove activity 06 from GRAC_ROLED object.

Regards,

Madhu.

[Colleen · Accepted solution]

Hi Madhu

I've interpreted the requirement as deletion is needed but require a validation first to make sure uses are not assigned. Therefore, you would not be able to restrict with the authorisation.

Regards

Colleen

[Former Member · Accepted solution]

Hi Colleen, hi Madhu,

yes - we disabled the approval steps in the role methodology and are directly maintaining the roles using GRC role maintenance and search menu.

My intention is even an Admin who is quite experienced could accidentially select the wrong role from the list and press delete button. Then the role would be removed from backend in worst case including all users that were assigned.

As there is no way to prevent this besides authorisation restriction for authorisation support team which is not advisable for us it seems the best to use Colleen´s proposal and activate the WF for role maintenance.

I am experienced somehow in the BRF+ rules using decision tables for access requests but haven´t looked into the role mainteance WF so far.

Is this initiator rule checking if users are assigned to the role included in the standard WF? Or does this need to be specified using BRF+ decision table or somethin else?

Thanks and regards,

Markus

[Colleen · Accepted solution]

Hi Markus

Role Approval WF is one of the MSMP Process Ids. Here's a link to a blog (please be patient with a little bit of confusion when I mixed up BRF+ to default role approvers vs the WF approval)

You could build the BRF+ initiator rule via the IMG program and then maintain the decision table. I haven't built it based on action type but perhaps the BRM has the option (differentiates between create, modify and delete). If you look on the GRC space you will find some good blogs for dblookups where you could take the idea and apply it to BRM scenario (find table with users to role assignment and check for the exists).

Ultimately, you need the BRF+ rule to return two results but there will be 3 checks: DEL_USERS - intended action is delete and users are assigned, and NO_USERS (whatever you want to call them) intended action is not delete and doesn't matter if users are assigned OR intended action is delete but no users are assigned.

Since you mentioned you're pretty good with BRF+, I think you'll have to have a play around and see if you can pick a structure. Key is finding the table in GRC with the users assigned for the check. If gets too hard, then looking for ABAP instead of BRF+ might become easier

Within MSMP you would handle the rule results and mappings like any other initiator rule. This would result into two paths so that you can send NO_USERS down the path with no stages. Then send the DEL_USERS down a path with an agent.

I haven't been able to protoype this solution (times like this I wish I had a system) so it will partly depend if possible to differentiate what the action/request type for BRM (can you identity delete action as an attribute in BRF+)

Regards

Colleen