How to enable automatic revocation in a SoD Policy Violation workflow?

I am using Sailpoint IIQ 8.4p2 with the SAP Direct Connector

I have created an entitlement-based SoD policy that detects a conflict between two entitlements in the SAP Direct application. When I assign both entitlements to an identity and run a refresh task with the option “Check active policies” enabled, the refresh creates a policy violation item for that identity. This triggers a workflow that presents a work item allowing the user to either keep or revoke one of the conflicting entitlements:

If I choose to revoke one of the entitlements, another work item is created to perform the revocation in the target application. At this point, I would expect the revocation to happen automatically, but instead it seems to require manual intervention or additional steps .

According to the SailPoint documentati on:

“The Revocations can be done automatically, if your provisioning provider is configured for automatic revocation, by generating a help ticket, if your implementation is configured to work with a help desk solution, or manually using a work request assigned to a IdentityIQ us er.”

https://documentation.sailpoint.com/identityiq/help/policies/working_with_policy_violations.html

My question is: How can I enable automatic revocation for the SAP Direct Connector (or any connector) so that when I approve the revocation in the policy violation workflow, the revocation is executed immediately without creating a manual work item?

Any guidance on the necessary configuration steps would be greatly ap preciated.

Thank you.

@HPALACIO can you please share your Entitlement SOD policy configuration.

Hi @HPALACIO

In Sailpoint automatic revocation only works when the target application supports direct provisioning.

Check the SAP Direct connector has provisioning enabled the entitlement schema supports the Remove operation, and the application is configured for direct connector provisioning.

Are the revoked entitlements from a connected application? SailPoint will automatically generate a provisioning plan for connected applications while it will generate a manual work item for the disconnected sources.

As you mentioned you are using Sap direct connector, and the provisioning is automated, why the workitem is raised for access removal??

This is not right, as for connected system Sailpoint will do it. Tell me one thing, when you do provisioning to the app using this connector, are you creating work item for creation or removal?? generally this is done for disconnected systems, and not for automated systems

@SivaprakashRNTBCI this is the Entitlement SOD policy:

<?xml version='1.0' encoding='UTF-8'?> control descripcion advice

@kallajayaram I tested the application, and is supported the remove operation, for example when I request remove an entitlement in LCM in Manage Access ans this removes the entitlements in the application directly.

@r_pragati Yes the revoked entitlements is form a connected application in my case is a SAP Direct Application, unfortunately , it’s not working that way.

@naveenkumar3 That’s the big question. When I request a access for a user in the manage access quick link, the entitlements is added to the user account in SAP or the account is created with the entitlements, AN work item is not created for creation or removal, directly in the application

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Policy PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Policy certificationActions="Remediated,Mitigated,Delegated" configPage="entitlementPolicy.xhtml" executor="sailpoint.policy.EntitlementSODPolicyExecutor" name="SAP CUA SoD" significantModified="1771347232979" state="Active" type="EntitlementSOD" typeKey="policy_type_entitlement_sod" violationOwnerType="Identity">
  <PolicyAlert disabled="true" escalationStyle="none"/>
  <Attributes>
    <Map>
      <entry key="sysDescriptions">
        <value>
          <Map>
            <entry key="en_US" value="SAP CUA SoD"/>
          </Map>
        </value>
      </entry>
    </Map>
  </Attributes>
  <ViolationOwner>
    <Reference class="sailpoint.object.Identity" name="hfpalaci"/>
  </ViolationOwner>
  <GenericConstraints>
    <GenericConstraint name="new rule" significantModified="1771347232979" violationOwnerType="None">
      <CompensatingControl>control</CompensatingControl>
      <Description>descripcion</Description>
      <RemediationAdvice>advice</RemediationAdvice>
      <IdentitySelector>
        <MatchExpression>
          <MatchTerm name="Roles" type="Entitlement" value="CD1CLNT100\/SAPSLL/LEG_CRM_CUS_IF">
            <ApplicationRef>
              <Reference class="sailpoint.object.Application" name="SAP CUA"/>
            </ApplicationRef>
          </MatchTerm>
        </MatchExpression>
      </IdentitySelector>
      <IdentitySelector>
        <MatchExpression>
          <MatchTerm name="Roles" type="Entitlement" value="CD1CLNT101\SAP_CRM_ECO_ISA_WU_B2B_AUCTION">
            <ApplicationRef>
              <Reference class="sailpoint.object.Application" name="SAP CUA"/>
            </ApplicationRef>
          </MatchTerm>
        </MatchExpression>
      </IdentitySelector>
    </GenericConstraint>
  </GenericConstraints>
</Policy>

Hi @HPALACIO As per your conversation, it looks like auto provisioning is enabled at the connector level since it is provisioning through access requests. To debug further, can you print the provisioning plan in the before provision rule? Share it here if possible.

Thanks,

PVR.

Hi @HPALACIO ,

Tell me one thing: when you run the Identity Refresh and the violation is detected, a **work item is created with type RequestViolation, correct?

If that is the case, the RequestViolation work item is assigned to the violation owner only to make a decision (Keep or Revoke). This is not a removal request. No provisioning happens at this stage.

Once the owner makes the decision and completes the work item, SailPoint then triggers the actual remediation. Since this is a connected system using the SAP Direct connector, the provisioning/removal is automated and no manual intervention is required.

So the work item is raised only for decision making, not because the system is disconnected.

@HPALACIO Can you share the 2nd work item details?. Is it actually for provisioning or to provide any additional information? sometimes SailPoint will present form workitem to user to get input which are required for provisioning.

@HPALACIO Is it possible for you to share your policy xml? and are you creating a separate workitem using the Policy Violation Workflow? i have tested this in my system, as soon as i revoke and save, it revokes the access.

@Peddapolu I attached the provisioning plan in the before provision rule.txt file with the plan.

@naveenkumar3 Yes, that’s correct, I attached the file Reproduction Steps.pdf with the detalis of the process.

@SivaprakashRNTBCI I attached the file Reproduction Steps.pdf with the detalis of the process.

@neel193 I attached the file Policy-SapCuaSodTest2.xml

Thank you all for your help!

Reproduction Steps.pdf (1.0 MB)

provisioning plan in the before provision rule.txt (1.9 KB)

Policy-SapCuaSodTest2.xml (1.9 KB)

Hi @HPALACIO Thank you for sharing the details. The main part, the application definition and integration configuration, is missing. If you have it, please share.

Thanks,

PVR.

Hi @Peddapolu thanks for the reply, I attached a log file with the application definition and integration configuration.

SAP CUA Log.txt (106.5 KB)

Hi @HPALACIO Reviewed logs: Your application looks good to me. There’s no way to create a manual work item in the application. Let’s have a quick private chat! it’s Very interesting point.

Thanks,

PVR.

@HPALACIO One more question.. Do you have PROVISIONING feature string still available on your application: SAP CUA?

@neel193 Yes, PROVISIONING is enabled, I create and update users with this connector.

@HPALACIO was this issue resolved?

@r_pragati Unfortunately not.

@HPALACIO if you want connect, ping me in chat. to understand this issue!.

Thanks,

PVR.