Understanding the IdM 7.2 – GRC10 interface

In this blog post I would like to share with the community some experiences regarding the IdM 7.2 <-> GRC10 integration.

This integration can easily turn out to be a tedious topic, in particular if things don’t go smoothly from the beginning. The documentation (I’m referring to

SAP NetWeaver Identity Management Compliant provisioning using SAP BusinessObjects Access Control Configuration Guide)

contains some charts how the communication flow goes and where which protocol is used (e.g. in the chapter “Introduction”). Then, it also explains in detail the purpose of the various tasks which is certainly very helpful (in the chapter “Task execution process description” starting on page 35). Here in this document, I’d like to focus on 2 things to clarify things a bit more:

• How does the communication between IdM and GRC really work? We’ll have a detailed look at that.
• Something goes wrong with the communication between IdM and GRC. What should I do?

Let’s start with the first point. We know from the documentation that when IdM communicates to GRC it performs an LDAP write operation to the VDS. The VDS “translates” this call into a web service call to GRC (compare again chapter “introduction” of the documentation). But how does this really work?

In the above screenshot you can see the toLDAP pass that creates the GRC request.

Now the VDS will take the parameters IdM provides (user first name, lastname, requested roles, validity dates) in the LDAP call and submit a web service client call to GRC10. If all goes well, GRC10 will reply SUCCESS and provide the request ID in GRC10. And now comes the tricky part. What will VDS do with this information? The toLDAP pass type doesn’t allow to handle complex return information. It only tells you “write operation successful” or “write operation failed”. This is why the VDS doesn’t send the information back to the IdM runtime. Instead, the VDS will write all return information from the web services directly to the IdM database as context variables. If the runtime needs it, say for a check in a conditional task then it needs to go to the database and read it (using either a SQL query for mxpv_audit_variables or the script function uGetContextVar). So the information flow between 7.2 and GRC10 is like in the below figure.

When IdM is querying information from GRC then the information can be returned to the IdM runtime. But even in that case the GRC provisioning framework uses context variables to store the information in the database.

2 examples

• If the CUP request creation is successful the VDS creates the context variable MX_GRC_REQUEST_ID. In the above screenshot check the task “Write Request Id and opt. start polling” (the one right below “Submit AC Request”) will execute the script sap_grc10_WriteRequestId2PVO. The first thing this script does is to read the context variable and store it in the attribute MX_AC_REQUESTID of the pending value.
• See the below screenshot. When IdM polls for the status (in this blog I only consider the polling scenario) it performs a LDAP read operation. The result is stored in the context variable GRCSTATUS where the subsequent conditional task picks it up. The SQL query is “SELECT VarValue FROM mxpv_audit_variables WHERE VarName=’GRCSTATUS’ and AuditID=%AUDITID%”.

So much about the IdM part of this interface. We’ll see in the second part how we can get more insight into the web services area. I’d like to mention that in the GRC provisioning framework there is a quite complex encapsulation of what we describe here with pending values and approval tasks etc. (for more information check one of my earlier blog posts). I guess the purpose of this encapsulation is to create a smooth integration with the privilege assignment process in IdM. But from a technical perspective you can also use the above toLDAP pass to create a CUP request independently of privilege assignments and pending values in IdM. I have done this for 2 customers. There, the GRC integrates into a custom request workflow scenario and the GRC part works completely without pending values. So much about part 1.

Now let’s cover the second item in our list: Something goes wrong with the communication between IdM and GRC. What should I do?

To illustrate how this can look like I’ve copied an error message I had to deal with a lot recently:

The error message doesn’t really tell you much. Unfortunately, there is no more specific information about what precisely went wrong. In addition, it is impossible to see how the data is manipulated before it is sent to GRC and which arguments in IdM map to which parameters in the web services.

If you get a very unspecific error message like above in the IdM log you should first open the VDS log. If configured appropriately (debug mode, see below screenshot) the VDS will print out the entire web service communication to the operations log.

Open the operations log at <VDS install directory>\configurations\<your config name>\log\operation.trc, search for “<GracIdmUsrAccsReqServices” and you should get the below hit:

What you see in the screenshot is the xml document that the VDS sends to GRC for creating the CUP request. It contains all information about the user, his attributes, the requested roles and so on. If you look at the trace file e.g. with Notepad you will have to check everything quite carefully because the xml document is stored as one big long string. Here is what it looks like if you configure notepad to use word wrap:

Wouldn’t it be great to have this as well formatted xml file so that we can study it easily?

So what we could do is copy this xml into a text file, save it with file extension .xml and open it with Internet Explorer. If you do this, it will look like this:

We can have a look now in detail which data is sent which is a good thing. But there is something missing here. If I know that with the values in the xml GRC will send back an error message I’d like to have a possibility to change these values slightly and resubmit in order to see if that also changes the result in GRC. So howcan I do that?

This is where soapUI comes into the picture. soapUI is a tool which allows you to submit web service client calls. It also allows you to do a lot more than that but what we’d like to do here is to submit the web service call to GRC ourselves. So please go ahead and download the free version of soapUI (http://www.soapui.org/). In order to leverage the power of soapUI we need one more small thing: The WSDL URL of the web service call that creates request in CUP. In order to get it, proceed as follows:

• Log on to the GRC box with SAPGui
• Start transaction soamanager
• A browser window opens. Log on and then click on Web Service Configuration

• Enter “GRAC*” in the search field and hit search. In the result list select “GRAC_USER_ACCES_WS” and press “Apply Selection”

• Click on “Show / Hide selected bindings or …”

• WSDL URL is displayed. Take it into the clipboard

Now let’s get back to soapUI. Now we can create a soapUI project with this WSDL URL. Start soapUI and then proceed as follows:

• In the main menu, select File -> New soapUI project

• Select a name, “Create CUP Request”, for instance, and enter the WSDL URL in the second field.

• Press Ok. You’re asked to provide logon data. Then you should see something like in the screenshot.

• Double click on “Request 1”. Now a window opens that shows you the xml structure.

For every question mark in the xml document you can enter a value. But we’re not going to find out which values we need to enter here. We’re simply going to use the xml document from above. So let’s replace the xml in the text pane by the xml we copied from the VDS operation log (see following screenshot):

The xml is now again one long text line. Fortunately, we can format the xml by right-clicking in the document and then “Format XML”:

Now, we’re almost there. We only need to maintain log on data:

.

Then we can start the call by clicking the green arrow:

With the request data from my test system I get an error message saying:

Processing Error. More details in WS Error Log (transaction SRT_UTIL) by selection with UTC timestamp 20130402125633

This is not a full explanation what went wrong but it gives me at least some information I can use to follow up. Furthermore, if I have a suspicion what the problem is I can modify the request and try again (in my example the problem is the German umlaut charater “ü” in the name which is wrongly encoded (see the last name in the screenshot)). I replace it by “u” and try again:

This time it worked. What is a simple change and retry with soapUI would have been a lengthy procedure in IdM: Change the identity, clean up failed assignments in the person record, reassign the privilege.

Summary

This post shows you some insight how IdM communicates with GRC, how the web service calls are encapsulated by IdM and the VDS and how you can get more information about what actually happens on the web service channel and how to debug it.