Re-provisioning occurring for removed roles for SAP GRC application

Which IIQ version are you inquiring about?

8.4p1

Please share any images or screenshots, if relevant.

Please share any other relevant files that may be required (for example, logs).

Please find below correlation configuration and account schema customization rule for SAP GRC application

import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import sailpoint.tools.Util;
import sailpoint.object.ResourceObject;

Logger log = Logger.getLogger(“CCEP SAP GRC Schema Customization”);
log.setLevel(Level.DEBUG);
if(object!=null) {
String objType = object.getObjectType();
if(Util.isNotNullOrEmpty(objType) && “account”.equals(objType)) {
String accountName = object.getIdentity();
String errorMessage = null;
String appConnName = application.getConnector();
String applicationName = application.getName();
if(Util.isNotNullOrEmpty(accountName) && Util.isNotNullOrEmpty(appConnName) && Util.isNotNullOrEmpty(applicationName)) {
if (null == connector) {
errorMessage = “Failed to construct an instance of connector [” + appConnName + “]”;
return errorMessage;
}
ResourceObject rObj = null;
try {
rObj = (ResourceObject) connector.getObject(“account”, accountName, null);
} catch (sailpoint.connector.ObjectNotFoundException onfe) {
errorMessage = “Connector could not find account: [” + accountName + “]”;
errorMessage += " in application  [" + applicationName + “]”;
log.error(errorMessage);
log.error(onfe);
return errorMessage;
}
if (null == rObj) {
errorMessage = "ERROR: Could not get ResourceObject for account: " + accountName;
log.error(errorMessage);
return errorMessage;
}
List roles = (List) rObj.getAttribute(“Roles”);
if(roles!=null) {
object.put(“Roles”, roles);
}
}
}
return object;
}

Share all details about your problem, including any error messages you may have received.

We are facing an issue where a role removed from SAP GRC is automatically re-assigned later via background provisioning.

Scenario:

  • Role CIMPROD/TPM_Regional_Sales_Director_SE00 was removed successfully.

  • Confirmed removed in SAP GRC.

  • SailPoint identity shows no such entitlement.

  • No Business Role / IT Role / Birthright involved.

Later during scheduled tasks (nightly), the role is re-added automatically.

Customization

There is a Schema Customization rule on the account schema that calls:

rObj = connector.getObject("account", accountName, null);
List roles = (List) rObj.getAttribute("Roles");
object.put("Roles", roles);


  1. Can this double-fetch in Schema Customization cause entitlement instability and trigger Provisioning Expansion during Identity Refresh?
  2. Has anyone seen similar behavior with SAP GRC AM connector?

when you said role was removed, at Sailpoint end, also did you see the business role removed from the user profile.

If business role still exists and then is identity refresh task with provision assignment checkmark, it will try to provision again.

Once the role is assigned to the user, in entitlement what do you see source as , what is the granted by flag??

Hi @kchengalvarayan ,

How this entitlement was removed?

And could you please confirm that this use case is related to business roles or not.

When you say Role, assuming it is schema entitlement attribute (“Role“), or is this entitlement linked with some business role or IT role.

Please elaborate

@kchengalvarayan this is likely due to AttributeAssignment (sticky entitlements). When access is provisioned through IIQ, it stores an AttributeAssignment on the identity. If the role is removed directly in SAP GRC (not through IIQ), the assignment record stays — so on the next identity refresh with “Provision Assignments” enabled, IIQ re-provisions it.
Check Debug → Identity → Preferences for that user and look for an AttributeAssignment entry for that role. If it’s there, that’s your cause. The fix is to revoke through IIQ so it clears the assignment, not directly in SAP GRC.

@kchengalvarayan Please confirm how are you removing the entitlements? Also, validate if attributeAssignment is being cleared properly. In case you are managing entitlements outside IIQ, you might want to disable setting attribute assignment in your LCM workflow by modifying the plan and set the attributeAssignment as false in the attribute request.

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(:heart:,:+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

@mandarsane yes this is related to entitlement attribute role not business role not entitlement is not linked to any business or it role

@abhi617 yes but in next aggregation we could see these roles/entitlements are coming in aggregation from SAP GRC in between gap this is happening.

@neel193 entitlements are not removed from IIQ, it seems when in aggregation the role values are missing in application end that is how we are assuming. yes we are managing entitlements in IIQ but aggregated through group aggregation.

Yes. If you are removing entitlements outside IIQ, then you should set assignment as false.

@neel193 to remove below attribute assignment we need to set assignment as false in plan level. could you please code snippet or any screenshot

@kchengalvarayan Here is the sample code form LCM Provisioning Workflow:

<Step icon="Start" name="Start" posX="25" posY="10">
    <Transition to="PreProcess"/>
  </Step>
  <Step icon="Start" name="PreProcess" posX="25" posY="10" resultVariable="plan">
    <Script>
      <Source>
        import sailpoint.object.*;
        import sailpoint.object.ProvisioningPlan.*;

    log.error("plan::"+plan.toXml());
    if(plan!=null){
    List accountList = plan.getAccountRequests();

    for(AccountRequest eachAcctReq : accountList){
    List atrList = eachAcctReq.getAttributeRequests();

    for(AttributeRequest attrReq : atrList){
    if(attrReq.getName().equalsIgnoreCase("groups")){
    attrReq.setAssignment(false);
    }
    }
    }
    }

    log.error("modified plan::"+plan.toXml());
    return plan;
  </Source>
</Script>
<Transition to="Initialize"/>

</Step>
  <Step icon="Task" name="Initialize" posX="134" posY="10">
.... Rest of the workflow.


Note: Found a fix?Help the community by marking the comment as solution. Feel free to react( :heart:, :+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

@neel193 can we try to remove attribute assignment from user profile and raise remove request on that case this retrigger can be avoided right. the above plan is fine for new users but for existing users we need to do a clean up

@kchengalvarayan Yes. This is for new users. For existing users, you can write a pre refresh rule or a rule runner task to do the one time cleanup .

@neel193 thanks for suggestion moreover we break our plan in our initial stage of workflow please refer below plan at time of the lcm workflow and at before provisioning rule.

Cleaning is done at identity level with rule runner task means just removal of attribute assignment should be done right? or please correct my understanding if there is an error.

LCM workflow plan
<ProvisioningPlan>
  <AccountRequest application="CCEP SAP GRC AM" op="Modify">
    <Attributes>
      <Map>
        <entry key="attachmentConfigList"/>
        <entry key="attachments"/>
        <entry key="id" value="d1378c6199331b3981994686b5161438"/>
      </Map>
    </Attributes>
    <AttributeRequest assignmentId="ed1d6b3a1f244083bc0e950c831580df" displayValue="DE2100/CP_GLOBAL_AUDITORS" name="Roles" op="Add" value="DE2100/6D90E436B1E21FD09FB4617298673C44">
      <Attributes>
        <Map>
          <entry key="assignment" value="true"/>
        </Map>
      </Attributes>
    </AttributeRequest>
  </AccountRequest>
  <Attributes>
    <Map>
      <entry key="source" value="LCM"/>
    </Map>
  </Attributes>
  <ProvisioningTargets>
    <ProvisioningTarget application="CCEP SAP GRC AM" assignmentId="ed1d6b3a1f244083bc0e950c831580df" attribute="Roles" value="DE2100/6D90E436B1E21FD09FB4617298673C44">
      <AccountSelection applicationId="d1378c60973b1bb58197c0d9f46b0642" applicationName="CCEP SAP GRC AM" implicitCreate="true"/>
    </ProvisioningTarget>
  </ProvisioningTargets>
</ProvisioningPlan>

before provisioning plan
<ProvisioningPlan nativeIdentity="SPDE00000527" targetIntegration="CCEP SAP GRC AM" trackingId="03f8963e684b4f0ea8b8c245a8315caf">
  <AccountRequest application="CCEP SAP GRC AM" nativeIdentity="SPDE00000527" op="Create">
    <Attributes>
      <Map>
        <entry key="attachments"/>
        <entry key="flow" value="AccessRequest"/>
        <entry key="id" value="d1378c6199331b3981994686b5161438"/>
        <entry key="interface" value="LCM"/>
        <entry key="nativeIdUpdated">
          <value>
            <Boolean>true</Boolean>
          </value>
        </entry>
        <entry key="operation" value="EntitlementAdd"/>
      </Map>
    </Attributes>
    <AttributeRequest name="Roles" op="Add" value="DE2100/6D90E436B1E21FD09FB4617298673C44"/>
    <AttributeRequest name="First Name" op="Add" value="Martial"/>
    <AttributeRequest name="Last Name" op="Add" value="Melsen"/>
    <AttributeRequest name="Email" op="Add" value="mmelsen@devccep.com"/>
    <AttributeRequest name="Roles" op="Add" value="DE2100/F9FFE727C29B1EDFBC8AC506C1251B55"/>
    <AttributeRequest name="System" op="Add" value="DE2100"/>
  </AccountRequest>
  <Attributes>
<Map>
      <entry key="appName" value="CCEP SAP GRC AM"/>
      <entry key="identityRequestId" value="0000036502"/>
      <entry key="isGRCReq" value="NO"/>
      <entry key="requester" value="SPDX80118007"/>
      <entry key="source" value="LCM"/>
    </Map>
  </Attributes>
  <Requesters>
    <Reference class="sailpoint.object.Identity" id="d1379021946d184481946e3b449037c6" name="SPDX80118007"/>
  </Requesters>
</ProvisioningPlan>

@kchengalvarayan Yes, if you remove the attributeassignments from the identity, it will block the auto reassignment if entitlement removed outside IIQ. for future requests, above plan looks good.

@neel193 thanks solution worked perfectly I’m preparing a rule runner one time rule for clearing this attribute assignments from user profile is there any reference rule do you have?