For quite a while now I think that the GRC provisioning framework seems to be used quite heavily and it might be worth to publish something about it in a blog post because I work a lot with it myself and I find it hard to understand and more importantly hard to debug.
So I will share some explanations with the readers of SDN here in this post.
I am not going to rephrase the installation documentation, how you need to instrument repositories and perform initial loads. My starting point is the add member task setting on a repository:
I had already discussed the add member task setting in one of The specified item was not found.. Only difference was that in that post, I had set the MX_ADD_MEMBER_TASK attribute on a role whereas here it is set on the repository. If it comes to privileges, it doesn't make a difference whether the approval task is configured on the privilege itself or the repository the privilege is linked to.
So let's focus what happens in this approval task. One of the things that makes the GRC provisioning framework hard to understand is the fact that if uses a huge lot of scripts. I try to describe the big picture a bit, however, I am not going to discuss the purpose of every single task in the tree.
Let's recap a bit. I had explained in The specified item was not found. that if you configure the add member task this makes role or privilege assignments result in the creation of a pending value. That pending value is then sent into the task configured as add member task. AC Validation in this case.
Somewhere down the road, the GRC provisioning framework will send an LDAP request to the VDS with a lot of information and the VDS will submit a WebService call to GRC. This web service call will create a GRC request and the approver / risk analyzer will see the request in his/her inbox.
What you see in the screenshot is the toLDAP pass that submits the data to the VDS. Here, I'd like to discuss some things. First of all, what happens until here is some preparation work that is not so important if you try to get the big picture. What is important is that the user might have requested several privileges but only one pending value goes into the AC Validation workflow. This is a built in concept called privilege grouping. Privilege grouping means that some pending values are grouped together because they are considered as one single request. Much the way you wouldn't want to bother an approver with 3 individual requests instead of one request which contains the 3 roles (at least if they have been requested together) you want to send the 3 roles as a whole to GRC.
SAP ID Mgmt groups the pending values by an attribute called MX_PRIV_GROUPING_GUID. The pending values that belong to one group share the same value.
In the above screenshot you can see that ROLEDATA is computed by a function call. And if you look into these functions you will find that the grouping guid is used to find the roles the user is requesting. Here one snippet:
This snippet is taken from the function sap_getPendingMsKeysInGroup which is being called in the preparation task Prepare AC Request which is called directly before the Perform Risk Check task group. This preparation task sets the context variable GROUP_PENDINGMSKEYS_PRIVILEGEMSKEYS. This variable (as the name indicates it contains the pending value mskeys and privilege mskeys of the group) is then used to compute the list of roles that is to be sent to Access Control in the request.
So far about pending values and grouping. The tricky thing is if something goes wrong. If you request 3 privileges in some Request Privilege IdM UI, the status of your privileges will be displayed as pending until an approver in GRC approves and IdM applies the pending values. But if e.g. GRC is down or something fails on the network no approver in GRC will ever see the request. What happens to the pending values? They need to be cleaned up. Maybe you say "ok, I have some inconsistent data in the DB, but can't I just reapply for the privileges when the problems with the network is solved?". Unfortunately not. Until the pending values are deleted, the user won't be able to reapply. If he does, nothing will happen. And nobody will be notified that there is something wrong. Fortunately, there is an error handler which automatically cleans up the pending value if something goes wrong. But I have seen many cases where this did not work properly. The pending values stayed in the system until somebody deleted them - and until then, they created a lot of confusion.
Fortunately, there is one relatively easy way to mitigate this. You can write a simple report about all pending values in the system. If all goes ok, pending values are deleted from mxi_values so the risk that the report will grow too big is pretty low (if it does anyway, then you have another problem you should address first). By some easy SQL filter stuff you should be able to exclude all pending values that do not relate to GRC (for example those pending values that deal with values that become valid in the future, see The specified item was not found.).
Hope you liked this post. If I find the time, I'll post a blog about how to deal with GRC integration and business roles.
- SAP Managed Tags:
8 Comments
