Auto approval Roles without SoD GRC 10.0

[Former Member]

Hi everyone,

I am designing the Workflow for the Access Request in GRC 10.0 and the main idea is avoiding BRF+ rules, so let me explain you my solution:

I use the initiator and the GRAC_MSMP_DETOUR_SODVIOL rules.

1)Create one path for the No SoD condition. It has no stages.

2)Create another one for the SoD condition. The stage would be the role owner stage.

Can do you think about it? Is there any step I am not considering?

Thank you very much for your responses!

[Former Member · Accepted solution]

Hi John

I have a better solution for you in case you want to follow.

Create 1 stage workflow with standard initiator provided by SAP  which will be called Role_Owner where you check for risk analysis and if there is any SOD's then it will take a detour path with 1 stage of compliance where after the risk is mitigated it will be auto-provisioned post approval at that stage.

Else if there is no SOD then at Role owner stage  just the role owner need to approve and it will be auto provisioned.

Let me know if it works for you.

Regards

Pradeep

[Former Member · Accepted solution]

Thank you very much for your response.

The way you described is exactly what I have configured in the Workflow. My question is that if there is no SoD, the role owner would not need to approve the roles because they should be auto-approve.

Do you know how could it be done?

Thanks in advanced!

[Former Member · Accepted solution]

Hi Pradeep,

Thank you for your answer, but the thing is that I need that if the roles that have no risks, they should be auto-approved. Do you know how can it be done?

Thanks again!!

[Former Member · Accepted solution]

Hi John

To check for Risk and detour you need to have atleast 1 path  where the Risk checking will happen based on that if risk is there then it will take the Detour path and if not then it will be approved there and auto -provisioned.

Regards

Pradeep

[former_member193066 · Accepted solution]

Hello,

For initiator rule you must have that in either header or line litem of a request.

either rolename or connectr or request id or request type etc.

your requirement would require atleast 1 stage to detemine the SOD  and routing rule you can use.

you can create a new data element under GRAC_S_REQUEST_RULE_LINE. them use it.

Regards,

Prasant

[simon_persin4 · Accepted solution]

Hi John,

Whilst I can see your requirement, the question is how will you check whether the roles have SOD violations or not in the access request?

They could be contributing to an SOD or critical access violation depending on the way in which the roles are assigned to the users.

Unless you evaluate the Risk analysis at the point in time then you'll never know. You can set the risk analysis to run automatically but that will only consider the default values and may therefore miss elements in the reporting.

You should really have at least one human interaction stage initially to certify that the analysis is done and that the request is genuine & appropriate but then it can be auto-provisioned from there onward.

Why are you trying to avoid BRF+ rules? Its not that hard and really enhances the solution by enabling you to configure proper behaviours based upon more complete use cases than simply hoping that you can align to the standard SAP template.

Simon

[former_member655817 · Accepted solution]

Hi John,

You can combine the logic of the SOD violations determined from the function module GRAC_MSMP_DETOUR_SODVIOL in the initiator rule . Now the initiator rule determines two results on request submission. One result with SOD violation and other without violations. Route the no violation result to a No Stage path and the one with violations to a Role Owner Path.

Regards,

Shilpa

[Former Member]

Hi John,

Can you let me know whether you had any luck in creating workflow for scenarios you described

1)Create one path for the No SoD condition. It has no stages.

2)Create another one for the SoD condition. The stage would be the role owner stage.

I have created the workflow , but it is assigning roles to the users even though there are SoD Conflicts

One path is for provisoning if there are no conflicts

second path is for forwarding to security team

Step 1

Process Global Settings

Select Process ID >> GRAC_ACCESS_REQUEST  with Rule ID : GRAC_AR_INITIATOR

Escape Conditions

Auto provisioning failure : Set Escape Routing >> Escape path >> SOD Review >> Escape Stage : 002

Step 2

Maintain Rules

Select Rule ID : GRAC_AR_INITIATOR

Rule Results

1.GRAC_DEFAULT_RESULT

2.SODVIOL_DETOUR_PATH

Step 3

Maintain Agents

Not maintained anything

Step 4

Maintain Variables& Templates

Not maintained anything 

Step 5

2 paths

Path#1 :  GRAC_DEFAULT_PATH  with no stages ( Automatic Assignment of roles )

Path#2:  SOD Review ( Custom path name )

Maintain Stages in Path#2

Stage Config ID : GRAC_SECURITY

Agent ID : GRAC_SECURITY

Routing Enabled: Yes

Rule ID : GRAC_MSMP_DETOUR_SODVIOL

*** Intention is to route any SoD conflicts to Security team if there are any risks . If no risks found , then create user without any approvals***

Step 6

Maintain Route Mapping

Rule ID : GRAC_AR_INITIATOR

Rule result : GRAC_DEFAULT_RESULT

To Path ID : GRAC_DEFUALT_PATH

Rule ID : GRAC_MSMP_DETOUR_SODVIOL

Rule result : SODVIOL_DETOUR_PATH

From Path : GRAC_DEFUALT_PATH

To Path: SOD REVIEW ( Custom path created)

Step 7

Activate

UserID has been created and roles assigned even though there are conflicts. Ideally it should check the path SOD REVIEW and forward this to Security Team for approval

Can you let me know what went wrong ??

[Former Member]

Stage 1: - fictitious Agent

              - escalation type = Skip to Next Stage

              - time = 1 min

              - no notifications

              - routing SOD

stage 2: Role Owner

regards.

[Former Member]

Hi Leon,

That's a easy logic/solution. Did you implement that and if the solution works/successful . Please share your experience.

Thanks,

Prasad

[former_member193066]

please check this useful for requirement like your.

example based on role, but you can refer for your initiator condition

http://scn.sap.com/community/grc/blog/2013/03/15/using-brf-db-lookup-to-create-complex-msmp-rules#co...