In an IdM 7.2 – GRC 10.0 Integration, ideally all role assignments would go to GRC-AC (Access Control) for Risk Analysis (SoD Checks). There would need to be a GRC Admin who evaluates each requests and takes action accordingly. If there are no risks, the GRC Admin would approve the request and ultimately the roles would get assigned to the user in the back end systems. if there are risks, the GRC Admin would either reject the request or approve it after creating mitigation controls in GRC-AC.
Once the GRC Provisioning framework is imported, it would create a new repository called GRC10. Under the constants, there would be one called “GRC_MANAGER_ID”. If you maintain a valid user ID (which is present in GRC system), all the User Access Request from IdM will go to this particular user in GRC. I don’t think it is ideal to hard code a GRC Admin user ID as people keep changing positions and jobs.
The other option is, to leave “GRC_MANAGER_ID” blank. The system will try and do two things. It will first look for a Manager assigned to this Person (in IdM) requesting roles. If Manager is maintained for this user, the request will be forwarded to this Manager in the GRC Inbox. I don’t think this is a good approach as it is not necessary that every manager knows how to do Risk Analysis in GRC and moreover it is not their job function.
The next thing which the system will try and do (if even the Manager is not maintained for the person) is look for the default manager settings in GRC-AC. I prefer this approach.
Below is the configuration for MSMP Workflow for Access Request in GRC-AC. This needs to be activated for IdM requests to flow into GRC.
There is a standard agent “GRAC_MANAGER” which is used by default in the “Maintain Path”. This agent can be ignored and a new custom agent can be created which refers to a backend role.
In the below screen, you can see a custom agent being created of type “PFCG Roles” and Agent Purpose as “Approval”. This agent is linked in the “Maintain Path” stage.
Z_SECURITY_TEAM is a backend PFCG role and it needs to be assigned to GRC Administrators. Hence, all the users who have this backend role, will be able to see the User Access requests and action them.