Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member192665
Participant

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.

Labels in this area