SAP IdM 7.2 and GRC10 Integration: non-compliance role removal

[Former Member]

Hi IDM Gurus

I am new to SAP  IdM. Recently our client wanted to implement GRC 10 and SAP IdM 7.2 integration scenarios.

The scenario is documented in SAP IdM and GRC integration configuration guide as “compliancy provisioning (role add, non-compliance removal) for centralized scenarios”.

My understanding for “non-compliance removal” is when an access request is received for user role removal, the request is NOT sent to GRC for SOD check.

SAP has documented 3 steps which should achieve the “non-compliance removal” in GRC 10 and IdM 7.2 configuration document.

For example one of the steps is:

Setup 1:

• Define the attribute MX_DEL_MEMBER_TASK on the ABAP repository definition.   
• Define the attribute MX_ADD_MEMBER_TASK on the GRC repository definition.   
• On privileges, define the following attributes:

·         MX_REPOSITORYNAME: ABAP repository definition

·         MX_REPOSITORY_ADD_MEMBER: GRC repository definition.

What my problem is if I follow the instruction of Step 1, the design may not work.

The document says that” MX_VALIDATE_ADD_TASK/ MX_VALIDATE_DEL_TASK” should be set up to hold the reference of task AC validation from GRC 10 framework. As  I understand that task assigned to the attribute MX_VALIDATE_DEL_TASK always get executed first. The task assigned to attribute MX_DEL_MEMBER_TASK will not get executed at all.

Therefore when an access request to remove a role from a user is received, the task assigned to attribute MX_VALIDATE_DEL_TASK (i.e. AC validation task ) will be executed. As a result the request is sent to GRC AC for SOD check.

So where have I made the mistake in my understanding?

Please help

[srilakshmi_s2]

HI,

Please check Page No., 19 from this document link .

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d09f0171-02e8-2d10-be90-a4ad042a0...

"

MX_ADD_MEMBER_TASK/
MX_DEL_MEMBER_TASK

Hold the task ID of the task AC Validation from the GRC 10.0
Provisioning Framework.
The values are filled in automatically during the import of the
GRC provisioning framework. These attribute are only relevant
for the distributed provisioning scenario. For the centralized
scenario they will be set to "-1", meaning that no add/delete
member tasks are inherited and executed even if defined on the
repository definition.

MX_VALIDATE_ADD_TASK/
MX_VALIDATE_DEL_TASK
Hold the task ID of the task AC Validation from the GRC 10.0
Provisioning Framework.
The values are by default set to "-1", meaning that no tasks are
inherited and executed. These attributes are only relevant for the
centralized provisioning scenario where the GRC provisioning
framework is used for validation.

"

Best REgards

Srilakshmi S

[Former Member]

Hi Srilakshmi

Thanks for your help! The information you have quoted from the document is the source of my confusion.

One way it says the default value is -1 (i.e.no tasks are inherited and executed), another sentence says both attributes (MX_VALIDATE_ADD_TASK/MX_VALIDAT_DEL_TASK )hold task ID of the task AC validation.

Regardless what the document says, Our client using IDM system connects 2 back end systems (ECC and BI) and wants to use IDM and GRC integration compliance provisioning (role add, non-compliant remove) for centralize scenario.

So If I want to use set up 1 of this scenario to complete that requirement.

My set up is

1. MX_VALIDATE_ADD_TASK/MX_VALIDAT_DEL_TASK=1
2. MX_DEL_MEMBER TASK  on ABAP repositories( ECC and BI) : Assign task Id delete member task from the provisioning framework
3. MX_ADD_MEMBER_TASK on GRC repository: Assign Task Id  of AC  Validation
*4. On the privilege :
     a. Assign ECC and BI repository definitions  to: MX_REPOSOITY NAME
     b. Assign GRC repository definitions to MX_REPOSITORY_ADD_MEMBER.
(*Note: item  4 can be achieved by modify the pass Enrich role privilege in AC10.0 –initial load- centralized provisioning job)

Do you think this set up will achieve my requirement?

Best Regards

[Former Member]

You're correct that the validation steps execute before the action is taken.  The other tasks might execute before or after the delete/add action has already taken place, so i would base your setup on that.