IDM request grouping issue

[Former Member]

Hi All,

We have designed our landscape to provision to SAP systems via GRC. IDM is sending add/remove role request to GRC via VDS-GRC web service but request is not properly grouped and logged in GRC. Here is the example:

There are two positions named P1 and P2 which has 2 and 4 tech roles within it.

Position-1 has tech role A and B

Position-2 has tech role A,B,C,D

User already has Position-1 and tech role A and B. Now user's Position-1 is getting replaced by Position-2. In this scenario following requests are getting logged on GRC:

1. One request to remove tech role A and B

2. One request to add tech role C and D

3. One request to add tech role A

4. One request to add tech role B

Note : All tech roles are from same GRC repository.

As per my understanding, this many requests should not be there when we are using GRC repository constant MX_PRIV_GROUPING_ATTRIBUTE = P:0

I have also observed "Write RequestId and opt. Start Polling" this job is getting executed even before "AC Submit requests" on position replacement even. This job is getting executed number of times based on number of common tech roles.

Any thought why requests are getting splited like this?

Thanks,

Dhiman Paul.

[Former Member]

Hi Andrew,

Many thanks for your detail reply.

Could you please guide me where I need to see to club all these requests? Could you please suggest me an approach or tell me which script I should look into.

Thanks,

Dhiman Paul.

[Former Member]

Dhiman,

The aggregation of the privileges into one request is done via custom javascript that we attached to our Prepare AC Request job in the GRC 10 workflow.  It was modified so that it would look up what privileges are assigned to the IdM business role(s) prior to it being submitted to GRC and subsequently approved.

The script that should be modified is: sap_grc10_prepareRiskCheckExecution

This script can be modified to look up all the privs assigned to all roles requested, aggregate them into one object/array, then pass (return) that information along with all mskeys (privs/roles/pvo)back to the pending value for the remaining GRC tasks.  This customization is required in order for AC Polling to kick off (which by the way needs to have the GRC10 repository explicitly assigned):

This explicit GRC10 repository setting must also be on the Submit AC Request:

Lastly, you MUST have the Risk Validation job (that also comes with the GRC 10 Framework) in the GRC 10 WF so that when your request comes back from GRC it will provision (or not) based upon the status returned from GRC.

One more thing, the grouping should be P:4 not P:0

There are a lot of nuances and gotchas in this integration but the above should be helpful to get you on the right path.

[Former Member]

Dhiman,

We have done something almost exactly here.  We actually submit the request in IdM, it goes to GRC for RA and SoD analysis, then comes back and is provisioned based upon approvals.  We had the option of allowing GRC to provision, but our mission was to utilize GRC just for RA and SoD analysis but allow IdM to handle all approvals, notifications, and workflow.

By default, IdM is a MX_PRIVILEGE-based system, so it makes sense that grouping of the roles into one request for GRC would be custom.  Though we see it makes sense to do it at the role level, the current release of IdM 7.2 will require some customization.  We had a conversation with SAP on this and this functionality would be a feature request for a future version absent the custom solution.  We then created a custom solution to actually group all requests into one big request so that GRC processed them as one request; (meaning one manager approval in the UI) this was in addition to the GROUPING settings at the repository level.

Now that we have this workking, we actually have IdM in the picture from request to provisioning.

You mentioned the Write RequestId and opt. Start Polling job.  This job should be in the actual GRC WF.  When it kicks off it calls the AC Polling job selected in the GRC10 repository constants in the MX_AC_POLLING_TASK attribute.  It also checks to see if the MX_AC_POLLING_ENABLED attribute in the GRC10 repository constants is set to 1.  The AC Polling job is a part of the standard GRC10 framework.

This GRC 10/IdM 7.2 integration has been very interesting to say the least, but it does work.  However, it does (currently) require some customizations to get it to work.