How to create Detour in MSMP Workflow?

[Former Member]

Hello GRC Experts,

we are implementing GRC Access Control 10.0 with all four components: CUP, BRM, EAM and RAR.

We have customized the CUP and BRM Workflows without Detour rules, they are working fine so far. But now we have a following issue:

We would like to create Detour rules for CUP Workflow for the following Scenario:

1. Case: No SoD

Request-->Role Owner Approval-->Provisioning

2. Case: SoD

Request--> SoD Risk-->Security Stage-->Role Owner (if Security Stage approves, then Role Owner also approves)--> Provisioning

I have Created two paths in MSMP workflow:

1st Path is Default Path with only one stage: Role Owner Approval stage

2nd Path is SoD Path with two stages:

Default and Security Stage

I have tested the CUP Workflow after creating of the Routing Rule, but it seems, it doesnt work. I have assigned a technical Role to a User, who has SOD risks. Me as approval received a notification about new work item, then I approved the role, and afterwards the Role was assigned to a user, whitout beeing forwarded to a security stage.

Can you please give me an advice what I have to do in order to make it work?

Thanks in advance,

best regards

Sabrina

[Former Member · Accepted solution]

Hi Sabrina,

For the detour to work correctly you will have to map the route with detour routing rule to respective path in your case path number 2.

To make it to work you will need two stage path for main workflow in which you need to mark risk analysis mandatory in first stage and maintain the detour in second stage for detour if SOD.

Hope this helps you.

BR,

Mangesh

[Former Member · Accepted solution]

Hello Mangesh,

thank you for the advice. I maintained in the Default stage Risk Analysis as mandatory. Now at the Role Owner Stage, when I try to approve the request I receive the following message:

But where I can perform Risk Analysis? There is no Button for Risk Analysis. The Risk Analysis was already performed at the Role assigning stage with SoD Risk as result.

Regards,

Sabrina

[Former Member · Accepted solution]

Hi Sabrina,

Once you open request as approver goto

Tab "Risk Violations" here you will get the options to perform risk analysis.

BR,

Mangesh

[Former Member]

Hello "GRC Newie" ,

Just a suggestion:

Please consider stopping your hiding behind a fake name, and perhaps more of us will consider responding to your questions.

Cheers,

Gretchen

[Former Member]

Hello Gretchen,

Thank your for the hint. I really didnt know that nicknames arent common practice here.

The community is great, and I am very thankfull for your help.

Best Regards

Sabrina

[former_member193066]

Seems you need to get your initiator rule based on sod violation..

there are few documents available in scn .. you can look.

please be aware once you enable risk analysis at form submission .. it take little bit of time as analysis happens in foreground.

Regards,

Prasant

[Former Member]

Hello Prasant,

I already had a Problem with timeouts during the Risk Analysis in the request Submission stage. I asked the Basis to adjust the Parameter for http/s tp 160 sec.

To your advice: Is the GRAC_MSMP_DETOUR_SODVIOL not the right rule?

Regards,

Sabrina

[former_member193066]

follow this.. will help you.

Regards,

Prasant

[Former Member]

Prasant, thank you for the document, but it seems to be a very difficult solution. I would like to use MSMP Workflow with that rule 'GRAC_MSMP_DETOUR_SODVIOL'.

I was trying to maintain the workflow using this document:

AC 10.0 Customizing Workflows for Access Management, but there is not enough Information about detour creation.

Currently we have a Situation, where we have SoD in our request. Risk Analysis is performed during the request creation. After Risk Analysis the request is submitted. The Role Approver can approve or reject the request. Then it goes to the Security Stage. Security Stage can also approve or reject the request.

But we want to implement the following workflow: If the workflow identifies that there are SOD violations, it must make a detour direct to security Team, and afterwards to a Role Owner Stage. Is it possible to implement that workflow without configuring BRF+ Rules? I was assuming that it is possible. Please correct me if I am wrong. I think my main error lies in a wrong route mapping in Step No 6: Maintain route mapping.

It would be very helpfull if someone could give me an advice, who I can configure that workflow.

Regards

Sabrina

[Former Member]

Hi Sabrina,

Yes it is possible through GRAC_MSMP_DETOUR_SODVIOL, have you tried the solution I provided?

Where is the problem right now?

BR,

Mangesh

[former_member193066]

check thgis notes.

1783157 - Routing at Request Submission in case of SOD violations

[Former Member]

Hello Mangesh,

let me explain you my issue:

When I am creating an request for my test user (Role Assigning), I am performing a Risk Analysis during the request creation. As you can see, I have SODs in my request.

My paths:

I have created two pathes:

Path1: GRAC_DEFAULT_PATH: with one stage. Routing enabled. With the ID: GRAC_MSMP_DETOUR_SODVIOL. Escalation to a Specified agend (Security Team)

Path 2: Z_GRAC_DEFAULT_PATH (SOD Path)

with two stages:

001:Role Owner Stage (Routing enabled) to a specified agent

002: Security Stage: no Routing enabled.

The Problem is, even though I have SOD in my reguest, no detour to a second path is occuring.There is somewhere a mistake, but I dont know where.

Here is my Route mapping.

Please, give me an advice, what I did wrong.

The another issue which makes me surprised. When I run the Report: Risk Volation in Access Request, there is no Violation! But I have SOD violations (see Schrrenshot no1)

Why this Report didnt Show the violations?

I hope, I could make you cleare, where is the Problem now?

Default path is working fine, bur the detour is not working. And the Report doesnt Show the violations...

Thanks in advance

best regards

Sabrina

[Former Member]

Thank you Prasant! I will check it now.

[Former Member]

Hi Sabrina,

Frankly speaking I have not configured detour on SOD on request submission, in that case may be Prashant's note could help you.

Apart from this to work,(SOD detour not on submission but after risk analysis in first stage).

As I said in my one of last reply to you, you have to have two stages in main workflow to send it to detour if SOD exists, it will not work with one stage.

So create two stages in main workflow.

Main workflow:

Stage 1: risk analysis mandatory (May be manager approval)

Stage 2:  Activate detour routing here.

Do the mapping in route mapping. and it will work once your first stage approver run the risk analysis.

For your second query.

The link you are executing is from dashborad and dashbord reporting is offline reporting, so to bring data to these report you will have to firm run batch risk analysis.

Then you would get your data.

Let me know in case of any issue.

BR,

Mangesh

[Former Member]

1783157 - Routing at Request Submission in case of SOD violations says:

"To route the request at the time of submission based on SOD Violations, you can use the Function Module "GRAC_INITIATOR_SOD_VIOLATIONS" based rule, which is an Initiator Rule
and acts at the time of Request Submission.

But when I am trying to find this Rule ID, I cant find it in the list of the Rules:

Do I have to create this Function Module?

Thanks,

Sabrina

[former_member193066]

No,

You need to add it.

There are two function modules infact

GRAC_INITIATOR_SOD_VIOLAT_LI(Line Item Level)

GRAC_INITIATOR_SOD_VIOLATIONS(Request level)

and these are the rule result values.

NO_SOD_VIOLATIONS

SOD_VIOLATION

Regards,

Prasant

[former_member193066]

No,

You need to add it.

There are two function modules infact

GRAC_INITIATOR_SOD_VIOLAT_LI(Line Item Level)

GRAC_INITIATOR_SOD_VIOLATIONS(Request level)

and these are the rule result values.

NO_SOD_VIOLATIONS

SOD_VIOLATION

Regards,

Prasant

[Former Member]

Mangesh B wrote:


For your second query.

The link you are executing is from dashborad and dashbord reporting is offline reporting, so to bring data to these report you will have to firm run batch risk analysis.

Then you would get your data.

Let me know in case of any issue.

BR,
Mangesh

Hello Mangesh,

thank you for the hint. So, I run the Batch Risk Analysis twice (the first time it took 12 min), but my Dashboard still doesnt shows the SoD violations. When I am running a Risk Analysis during the request creation, I always have SoD violations.

Another Point: Does is have anything to do with my roles? When I am adding roles during the request creation to a user, there is a message that  role dont exist. The roles are created in the test system, and are uploaded to AC.

It seems to be the case that AC doesnt recognize those SoD Violations which are displyed during the request submission....Sorry for lots of questions, I really dont know what else to try.

Thank you,

best regards

Sabrina

[Former Member]

Hello Prasant,

I added the second Rule CRAC_INITIATOR_SOD_VIOLATIONS and respective Rule results.

I mapped the routes:

I started a request for Change Account, run Risk Analysis which displayed SoD Violations

But only the path: If now SOD_VIOLATIONS then to DEFAULT_PATH is working. There is no detour to a path Z_SOD_PATH.

Somehow the system doesnt recognize the SOD Violations and always takes the DEFAULT_PATH.

Sorry for asking you again, but do you have any idea what else I can try?

Thank you

best regards

Sabrina

[Former Member]

Hi Sabrina,

If you are not getting role in access request, how are you getting SOD ris analysis.

Also have you ran batch risk in full mode or incremental, please run it in full mode for first run so it gets all data?

Seems your user already have SOD due to present authorization and role you are adding not creating any SoD so request might not be getting violation (Not sure abt this but may be a possibility)

Have you ran auth synch?

Do you have roles in GRACROLE?

BR,

Mangesh

[Former Member]

Sorry, my mistake! I just have checked, I get this message: "The role xy doesnt exist on Default Connector xy" only  if I am creating a Business role. I think, this message is because I work with master roles, they are not assigned to users in my Default connector.

In GRACROLE I have above 170 roles in production Status.

I have run the followings sync Jobs in full mode:

Role Synch

User Synch

Role Usage Synch

Action Usage Synch

Repository Object Synch

Batch Risk Analysis

To your assumption: I have created a clean user, who only has only one uncritical role. Then I have assigned a critical role which contains many SODs. The Risk Analysis at user level during the request shows no violations. The Risk Anylysis after adding the critical role shows many SOD violations. But my request still takes the Default path, not the SOD path.

I am looking for further solutions...Will inform your if I will solve the problem.

[former_member193066]

hello,

it not that way.

add 1 rule.

GRAC_INITIATOR_SOD_VIOLATIONS

then add rule result value to it

NO_SOD_VIOLATIONS  and description give asPATHA

SOD_VIOLATION PATHB

and map it route map to each path.

save it.

then come back and change process initiator to GRAC_INITIATOR_SOD_VIOLATIONS

then save and generate version.

Regards,

Prasant

[Former Member]

Dear Prasant,

thanks for the advice. I followed your advice:

The Workflow is maintained correctly now. But still my requests take the DEFAULT_PATH (NO_VIOLATION), even though their new roles applied for assigned containing SoD violations. It is not an issue of the workflow anymore, it seems that the SoD Violations are not found/recognized by the workflow. The Report "Risk Violation in Access Request" doesnt show any violations in reguests.

Nevertheless thank you for your great help! Im sure it will help also others who will face the same problems like me.

I only have to solve the issue: why SoDs cannot be recognized, and my requesta always take the DEFAULT_PATH, even though the Risk Analysis during the request creation displays SoD violations.

Best regards

Sabrina

[Former Member]

Hi Sabrina,

As per your last post to Prashant.

Could you try creating custom path Z_XYZ and try to map it to Result NO_SOD_VIOLATION and generate?

Does your dashboard report working now?

Also before changing anything in present configuration, have you run risk analysis before submitting request? try this too.

Do you have 1071 activated with your present configuration?

BR,

Mangesh

[Former Member]

Hello Mangesh,

1071 is set auf YES. I have run FULL BATCH Risk Analysis yesterday and today, but the Dashboard sill doesnt Show any result.

I will try your advice with the custom path, and inform you about the result.

thanks a lot,

regards

Sabrina

[Former Member]

Hi Sabrina,

Please try running risk analysis before submitting the request.

BR,

Mangesh

[Former Member]

Hi Sabrina,

Try setting 1073 too and test with it.

BR,

Mangesh

[Former Member]

Hello Prasant,

I am still having issues with the MSMP Workflow. Let me please explain the details. Following your advice (Note 1783157 Routing at request Submission in case of SOD Violations) I added the rule

GRAC_INITIATOR_SOD_VIOLATIONS with the following results values:

SOD_VIOLATIONS - Z_SOD_PATH

NO_SOD_VIOLATIONS - Z_DEFAULT_PATH

I run the Risk Analysis before Submission. The Risk Analysis shows that the SOD risks exists. My requests go to Path Z_DEFAULT_PATH, despite of SOD risks. Normally my reguest must go to Path Z_SOD_PATH, because of SOD Violations.

I already have run RISK ANALYSIS in Batch mode, but the Dashboard Report doesnt show that my request have SOD violations.

What could be reason for this issue?

Config Parameter 1071 and 1073 set to YES. MSMP workflow are generated and activated without Errors.

thanks in advance,

best regards

Sabrina

[Former Member]

Hi Prashant,

Thank you for your explanation as to how the FM works, but one thing worries me. If the process initiator is changed to "GRAC_INITIATOR_SOD_VIOLATION" or "GRAC_INITIATOR_SOD_VIOLAT_LI", What happens in a situation where you require to raise a request for other processes such as custom "Request Types", or even a request for a EAM ID?  Implementing these FM's as the initiator seems to restrict how the workflow would work, compared to implementing a BRF+ rule.

Look forward to reading more about your experiences in this area.