GRC AC Role Removal without role owner approvals

[mhughes2]

Hello All,

I need some help with trying to set up a workflow that allows a user to request a role be removed from a users account without the request going to the role owner for approvals.

Currently using the default Workflow, if a submit a request for the removal of a role it automatically sends the request to the role owner to approve the removal action.

I would like input on the following:

1. Is there a way to use the default provisioning rules to complete this without having to create a custom BRF+ routing rule?

2. If this is not possible via the out-of-box processes, can I get some input on what I may be doing wrong with the custom BRF+ routing rule that I created:

Here is where I am at in the BRF+ routing rule:

I have created the below routing role ZBRF_ROUT_REMOVE_ROLE and have set the REQTYPE = 002 (Change)

PROV_ACTION = 009 (Remove Role)

For RULE_RESULT it was only a text entry field and when I left it blank and perform a simulation I got blank results. Looking at other posts I saw where someone said to populate it with a result name like (REM) and this will give me REM in my simulation but now I have no idea as to configure that rule result in the MSMP workflow to get it to recognize the correct action of "remove the role" without it going to the approver.

Any input as to what I am missing or if I have done this incorrectly would be appreciated.

I feel that if I can get some productive insight on this, it will help me understand some of the other BRF+ questions I am having.

[former_member226273 · Accepted solution]

Hello Michael,

The output of decision table has to be caught in MSMP.

Please create routing rule in MSMP (ID will be same as BRF+ function ID). In this rule result value REM and set a triggre value.

Now, in stage 6 of MSMP, create an entry for this routing rule ID, where the path and stage would be the one where you want to apply routing rile. The "To Path" value will be another path where the request with all roles to be removed has to be sent (in your case, the path without any stages).

Please let me know if you have queries on this.

Kind regards,

Yashasvi

[mhughes2 · Accepted solution]

Yashasvi,

Thank you for your time in responding to this. I have followed your instructions in what I think is the correct process but it still does not seem to be identifying my BRF+ requirements for Account Change, Remove access.

I have created the Rule ID as you stated with the following information inputted:

I also created the Route mapping so that it would come off the GRAC Default path for that Rule ID and go to the "No Role Owner" path which is empty (and works fine for my no role owner roles still)

I have created a couple of different requests and they all seem to me ignoring the new rule set as the Rule ID does not show up in my Provisioning audit log.

If you see something in my MSMP workflow that is incorrect please let me know.

If it is a BRF+ issue then I'll post pictures of how it is configured for your input if needed.

[Former Member · Accepted solution]

Hi Michael,

I got exactly what you are trying to achieve, the question I have for you here is what will happen if you want the same role to be added to the user, if the role will have a role owner and will it go for approval?

Thanks

Ramesh

[former_member226273 · Accepted solution]

Hello Michael,

Routing rule seems to be correctly defined.Did you get any error while activating MSMP workflow?

Please provide details of GRAC_DEFAULT_PATH and stage 020 where the routing rule is applied. Also, please verify that BRF+ application is activated.

Kind regards,

Yashasvi

[mhughes2 · Accepted solution]

Yashasvi,

I figured out what I had done incorrectly. I was treating the routing rule as if it would work on it's own without having to be added to the default GRC workflow path.

Once I updated the GRC default path to add the BRF+ routing rule to the Security stage it started acting semi-correctly.

I am now running into the issue that when I try to add a role back the BRF+ rule I created is for some reason seeing my request to add the role the same way it would see the removal and states that it is meeting the Detour condition rules of REM....which I don't get because the whole routing rule is supposed to be set to only see 002 (change) and 009 (remove) actions.

I am posting complete screens of all of my routes and Logs:

1. here you can see the "request access" triggered the routing rule because value REM was satisfied. But my BRF+ rule should have only provided that value with a 002 (change) and 009 (remove) action, and this was a 002 (change) and 001 (add)

Next is my default path Security stage

with my routing rule for the BRF+ remove role action.

for prospective here is the Manager Stage that contains my escape route for "no role owners" in case there is a request for a role with no owner (this was working fine before I added the BRF+ escape on the Security stage)

Finally the Role Owner stage of the Default path: as you can see there is not escape on this one.

Next is my Remove Role Path: Here is where I added stage 020 so that my Managers would approve all role removals. This path should only get triggered on a removal action but now ALL my requests are going to here.

Just for visual here is my "No Role Owner" path. This is also now not being used as nothing is making it to it since everything is now going to the "Role Removal Path"

Finally here is my routing tables:
BRF+ routing for role removal

and No role owner routing table:

finally here is the BRF+ rule that shows my logic:

Looking at Ramesh's reply it looks like he may be having the same issue as me OR he saw something I didn't..

[mhughes2 · Accepted solution]

Yashasvi,

I have actually answered my own issue and found the mistake in my BRF+ rule that I created.

I updated my Remove role rule in BRF+ to be an event based rule and then changed my Operand from a A "and" B statement to an "If all True" statement which meant that both A and B must be valid for the then statement to apply.

Thank you for your time and input on this.

I am assuming that if in the future I want to have multiple different items that trigger workflows outside of the default, then I am most likely going to have to create a custom initiator that contains all of my rules in it as well as the default actions?

exm: contractors get password disable or custom roles, locking accounts that are in a specific job status, ect...

[mhughes2 · Accepted solution]

Ramesh,

see my very last reply to Yashasvi. As long as I have correctly set up my BRF+ rule then the only time that workflow would trigger is with the Change + Remove action.

Once the role has been removed, I can then add it back which will follow my normal Default approval process because it does not meet the BRF+ custom role requirements. (adding back is Change (002) + Assign (006))

I have tested this a couple of different times and it is working as designed now.

[former_member226273 · Accepted solution]

Hello Michael,

Nice to know that your query is addressed. But here are few points I would like to mention:

1. It would be better to use Decision table in BRF+ insted of writing If.. Else statements. Very easy to maintain, and you can handle multiple conditions at one place.

2. Your comments says there are escape routes in Manager stage. the Escape route can only be set globally (step 1 of MSMP), and not on stage/path level. What you see in stages (step 5 MSMP), are Routing rules.

Please let me know in case of questions. Close the thread if issue is addresed 🙂

Kind regards,

Yashasvi

[mhughes2 · Accepted solution]

Yashasvi,

I guess I don't understand because I thought I was using a decision table.... This was the only way I could get it to see the two variables that I was submitting in the request.

Is the decision table set up at the same level as the If/Then statement?

Edit update Below:

I had set up what I thought was a decision table with the same criteria and it was giving me my original result which was to send ALL change requests through to automatic approvals. (as shown in my first screen shot).

I have actually found a document on creating a decision table and found that, I had originally created that type and this new decision table is again sending ALL change requests to a completed status. so my role assigns once I approve as Security it sends it down the REmove Role path for manager approvals and then assigns the role without role owner.

The only way I could get it to work for only a Change Status with a Remove action was to set up the If/Then.

[mhughes2 · Accepted solution]

Yashasvi,

I figured out what I was doing incorrectly on the BRF+ decision table initially. I have set up the Request Type as a Condition but had set the "Prov_Action" up as a result and not a condition. I have corrected that as shown below and now have a perfectly functioning Decision table.

Per your suggestion, I am going to remove the "If/Then" rule that I created and use the decision table now that it is working.

Again thank you for you patience and response, I will close this issue.