How legal values brought me in trouble

I was configuring the connection between SAP ID Mgmt 7.2 and GRC10 the other day. I thought I had done everything right. But I was hit by a really strange error message. Let’s recap.

1. I imported the GRC Provisioning Framwork
2. I configured the VDS and created a repositroy “GRC10” pointing to the VDS.
3. I ran the 2 initial load jobs which load all roles the GRC system has uploaded and enrich the ID Mgmt privileges with additional attributes (MX_AC_ROLEID, MC_AC_ROLETYPE, MX_APPLICATION_ID, MX_REPOSITORY_VALIDATE).

One of the new features in SAP ID Mgmt 7.2 is that there are additional hooks on privilege level. In 7.1, there was only the hook MX_ADD_MEMBER_TASK. It allowed to configure an approval process. Instead of assigning a privilege directly to a user, the system created a Pending Value Object and sent that Pending Value into the task configured in the MX_ADD_MEMBER_TASK attribute. In 7.2 there are MX_ADD_MEMBER_TASK and MX_VALIDATE_ADD_TASK which gives you additional options to hook into the privilege assignment process. MX_VALIDATE_ADD_TASK works in the same way as MX_ADD_MEMBER_TASK, only that it is executed first.

But there is another option. Instead of configuring MX_VALIDATE_ADD_TASK on each privilege, you can set this attribute on a repository and then set the name of the repository as attribute MX_REPOSITORY_VALIDATE on each privilege.

This is exacly what the standard integration with GRC10 does. The “commons” job sets the MX_REPOSITORY_VALIDATE attribute on each privilege that is uploaded from the GRC 10 system.

Now let’s come back to what got me into trouble. I had configured all this stuff (and I thought I had done well). But when I tried to assign privileges to users I got the following:

I had never configured any constraint on privilege level. So this error message was kind of really strange from the very beginning. I checked all sorts of things. Finally, I removed MX_REPOSITORY_VALIDATE from all privileges. After that, I could assign all privileges without any problem but no GRC workflow was triggered. The privs were assigned to the users right away, which wasn’t what I wanted, of course, but no big surprise, either. So my problem was somehow due to this validate/repository/whatever new mechanism.

By pure chance, I found the solution the day after. By pure coincidence. Meanwhile, I had created an OSS message and I’m not sure how many days the development support would’ve spent on this problem.

The problem was that I had configured a list of legal values on the attribute MX_REPOSITORYNAME because I had added this attribute to the advanced search of the entry type MX_PRIVILEGE (I wanted to be able to select only privileges from a specific repository). I had done this a long time ago already so I had almost forgotten about it. Then, when I needed to configure the GRC stuff I added the GRC10 repository to the system. Of course I didn’t add the GRC10 system to the list of legal values of the attribute MX_REPOSITORYNAME. And this was the reason of all my problems. Why?

Because when you have MX_REPOSITORY_VALIDATE=GRC10 configured on a privilege and you assign this privilege to a user then the system creates a pending value object and tries to set MX_REPOSITORYNAME=GRC10 on that Pending Value. But GRC10 is not a legal value for this attribute. So the creation of the Pending Value fails. As a result, the entire assignment attempt fails. And you get the error message “Value not legal for this attribute” in the User Interface.

I added “GRC10” to the list of allowed values for MX_REPOSITORYNAME and everything started to work like a charm.