Multiple User Group in SAP GRC

lherrera · April 22, 2025, 6:51pm

Hello,

I’m encountering some issues when creating accounts using the SAP GRC connector in ISC, as the documentation is not entirely clear. Specifically, I have questions regarding the User Group, System, and Valid To attributes of the account.

During account creation testing, the connector indicated that the required format for the User Group attribute is SystemID/User Group. Once adjusted to that format, the account creation was successful.

The main concern arises in scenarios where an account needs to be provisioned across multiple systems simultaneously (e.g., SAP ECC, SAP ARIBA, SAP FIELDGLASS, SAP BW, SAP BW4HANA, among others). For example, let’s say a single request is made for three roles across ECC, ARIBA, and BW. The connector indicates that the System attribute in the provisioning plan must be static (e.g., BWPCLNT500). However, this doesn’t make much sense when trying to provision several systems in a single request. Shouldn’t this attribute be dynamic, adapting to the corresponding system of each role?

The same concern applies to the User Group attribute. When creating accounts across multiple systems, how can this attribute be properly configured in the provisioning policies to ensure it is correctly assigned to each system? Based on the tests I’ve performed, the required format also seems to be static (e.g., BWPCLNT500/UserGroup), which becomes a challenge when accounts span multiple systems.

Additionally, I have a question regarding account enablement and disablement tasks. According to the documentation, the connector allows updating the Valid To date and the User Groups for all systems linked to an account using structures like the following:

<!-- Example to update the User Group -->

<AttributeRequest name="User Group" op="Set">

<Value>

<List>

<String>systemNameA/GroupName1</String>

<String>systemNameB/GroupName2</String>

</List>

</Value>

</AttributeRequest>

<!-- Example to update User Group Assignments -->

<AttributeRequest name="User Group Assignments" op="Set">

<Value>

<List>

<String>systemNameA/GroupName1a</String>

<String>systemNameA/GroupName1b</String>

<String>systemNameB/GroupName2a</String>

<String>systemNameB/GroupName2b</String>

</List>

</Value>

</AttributeRequest>

If I understand correctly, it is possible to send a list of values for the User Group attribute through provisioning policies, specifying the appropriate groups for each system. However, this brings me back to the same concern: how is this managed dynamically, considering that accounts may vary in the systems they belong to based on the request? Is there a way to parameterize these values without making them static?

I would greatly appreciate any guidance on how the connector handles the assignment of these attributes when creating accounts across multiple systems.

sukanta_biswas · April 23, 2025, 9:25am

@lherrera -

Below is a practical way to think about (and implement) System, User Group and Valid To when you use the SAP-GRC connector from Identity Security Cloud (ISC).

1 Why System is “static” during Create Account

What SAP-GRC expects	What the SailPoint connector does
Every user master record has one “logon system” (sometimes called the master or priority system). Additional systems are just line-items inside the same GRC request.	The System attribute in the Create Profile is therefore mapped as Static. You enter one value (for example `BWPCLNT500`) and that becomes the master record in the request. - Creating a Profile to Provision New Accounts

So, even when your request contains roles from ECC, BW, Ariba, etc., only one system ID is carried in the Create portion of the provisioning plan. GRC itself then propagates the user to the other systems when the line-items (the roles) are approved and fulfilled.
Bottom line: do not try to make System dynamic; pick the master system that makes sense for your organisation (often ECC or the system with the highest priority sequence in SPRO).

2 How to deal with User Group when roles span many systems

2.1 What the connector accepts

For modify operations (enable/disable, attribute sync) the connector can take a list in SystemID/UserGroup format:

<AttributeRequest name="User Group" op="Set">
   <Value>
     <List>
       <String>SAPECC6/ESS_USERS</String>
       <String>SAPBW1/INFO_USERS</String>
     </List>
   </Value>
</AttributeRequest>

This is documented in the “Additional Information ➜ Enable and Disable Account” section of the guide - Additional Information

2.2 Making that list dynamic

Because ISC build-in transforms cannot see the full ProvisioningPlan, you have two common patterns:

Option	When to use	How it works
Before-Provisioning rule on the GRC source	You already write BeanShell for GRC and need maximum control	1. Read `plan.getAccountRequests()`2. For each role line-item determine the `system` (it is the substring before the “/” in the role name)3. Build a `java.util.Set` of `system + "/" + desiredGroup` pairs4. Add one `AttributeRequest` for User Group (or User Group Assignments) with that list5. Return `true` so the connector proceeds
Rule-Type Transform returning array	You prefer the low-code UI and only need the list at disable/enable time	1. IdentityNow calls the rule transform 2. Inside the rule you look up the account’s Systems or last request’s roles (via SailPointContext) 3. Return a `java.util.List<String>` of the same `SystemID/UserGroup` pairs

Either way you do not have to hard-code values; you derive them from the entitlements or any business logic (country, cost-centre, etc.).

3 Setting Valid To dates for many systems

The same list approach applies. Example for a disable request on three systems:

<AttributeRequest name="Valid To" op="Set">
   <Value>
      <List>
         <String>SAPECC6/20251231</String>
         <String>SAPBW1/20251231</String>
         <String>SAPARIBA/20251231</String>
      </List>
   </Value>
</AttributeRequest>

Format must be SystemID/yyyyMMdd - Account Attributes

You can generate this list in exactly the same rule/transform that you use for User Group.

Key take-aways

System is intentionally static during Create → pick the master system. GRC will still process roles for the other systems. - Creating a Profile to Provision New Accounts
User Group/Valid To can target many systems by passing a list in SystemID/value format. - Additional Information
Build those lists on-the-fly with a Before-Provisioning rule or a Rule-type transform—no hard-coding required.
For large or complex environments, splitting the initial Create and subsequent Modify (attribute update) into two workflow steps keeps plans clean and easier to troubleshoot.

Cheers!!!

lherrera · April 23, 2025, 8:25pm

Thank you for your response, now I have a better understanding of how the connector works. However, I have a question regarding the System field. I conducted some tests for account creation in the destination systems, and the client raised an important concern: they do not find it appropriate to create an account in a system where roles were not explicitly requested.

To explain further, if I send a request to create (role assignment) accounts in the systems NEQCLNT500 (ECC) and BIQCLNT400 (BW), and in the policy I define the System field as G2DCLNT100, SAP GRC not only creates accounts in ECC and BW, but also generates an account creation request in G2DCLNT100 (SAP GRC), even though no roles have been requested for that system.

Upon reviewing the SAP GRC connector documentation, I found that there is an attribute called skipSystemItem, whose default value is false. When this attribute is set to true within the application XML, the first item in the RequestedLineItem containing the source system name is skipped in the call to the GracIdmUsrAccsReqServices API during the creation operation.

Based on this, would configuring skipSystemItem allow me to prevent the account from being created in G2DCLNT100 (SAP GRC) and ensure that accounts are only created in ECC and BW? Or am I missing something in my understanding?

I have one more question. The rules for SAP GRC, specifically the Before-Provisioning Rule you mentioned, do these need to be uploaded to the cloud by the SailPoint team? Is there no possibility of executing them in the VA ?

lherrera · April 25, 2025, 6:09pm

skipSystemItem allows provisioning to the selected systems without creating the account in the SystemID specified in the “System” field.