Remove entitlements while disable

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi Folks,

We have requirement that for some sources we need to disable the account only but for some we also need to remove the entitlements along with disable. So in lifecycle state when we toggle the option of remove all access it is going and trying to remove all access i.e. all entitlements.

Is there a way that we can specify that for which source the entitlements should be removed.

2

Hi @Amsingh1 ,

Yes you can configure this behavior per source using the ‘Services Standard Before Provisioning Rule’. You can have SailPoint support deploy this rule to your tenant (if not already available). Once deployed, you can patch individual sources with a json map describing the triggers & actions you would like to utilize from the rule (ie. remove all entitlements on a disable operation).

See below for an example config you can patch onto a source to remove ‘group’ type entitlements on a disable operation. You need to patch the cloudServicesIDNSetup config as well as the beforeProvisioningRule attributes onto the source:

            "cloudServicesIDNSetup": {
                "eventConfigurations": [
                    {
                        "eventActions": [
                            {
                                "Action": "RemoveEntitlements",
                                "Attribute": "group",
                                "Value": null
                            }
                        ],
                        "Operation": "Disable"
                    }
                ]
            }

        "beforeProvisioningRule": {
            "type": "RULE",
            "id": "<rule id>",
            "name": "Services Standard IdentityNow BeforeProvisioning Rule"
        }

Let me know if that helps!

Thanks,

Liam

3

So is this rule works for all connector?

4

Hi @Amsingh1 ,

The rule itself is generic and can be used with most sources. What matters is how you configure it per source.

Using the Services Standard Before Provisioning Rule, you can control disablement behavior on a source-by-source basis. By patching each source with the appropriate provisioning logic, you can decide whether a disable operation should only disable the account or also remove entitlements. This allows you to remove entitlements for specific sources while leaving others as disable-only, even when Remove All Access is enabled in the lifecycle state.

Just make sure to test the configuration in your sandbox tenant before deploying it to production.

Edit: you dont need to patch each source with the disablement logic, just the one source that needs to have the access removed along with the account disablement operation.

5

Ok Got it, so what i am thinking is that in the lifecycle state i will not enable remove all access and just for whichecver source entitlement needs to be removed in them we can patch the source. Will it be fine

6

Yes, only for those sources where entitlement removal is required in conjunction with account disablement.

1 Like
7

If the Workflow feature is enabled in your tenant, you can leverage it and define the entitlements to be removed from each source based on Lifecycle state change which you used to disable the account(s). Check this Workflow to remove ALL leavers’ standing access - Identity Security Cloud (ISC) / ISC Community Knowledge Base - SailPoint Developer Community. It comes with an advantage of flexibility like you can change the config based on your requirement at any time and don’t depend on cloud rule to be deployed.

8

Hi @liamkokeeffe just one clarification in the attribute, do we need to mention the entitlement type name or the attribute name that is mentioned as entitlement in account schema

9

@Amsingh1 If you are provisioning access using Access Profiles, you can achieve this.

In the Identity profiles, under life cycle management - for inactive/terminate life cycle state, choose the sources to delete and choose the access profiles that should be removed in that state.

Otherwise you can manage this in Before Provisioning rule for each source. Like for AD, you can remove the AD account’s memberOf for a specific life cycle state.

10

Hi @Amsingh1 ,

It would be the entitlement attribute name that is specified in the account schema.

Thanks,

Liam

11

Currently, Remove All Access in lifecycle state affects all sources. To selectively remove entitlements for specific sources, you have two options:

  1. Services Standard Before Provisioning Rule – Patch only the sources needing entitlement removal with custom provisioning logic. Don’t enable Remove All Access in lifecycle state; configure each source individually.

  2. Workflows – Use a workflow-based approach to define which entitlements should be removed per source based on lifecycle state changes, offering more flexibility without needing cloud rules.

12

If you want to use the remove all access in a lifecycle state, but want some access to be kept, you just need to define the access to be retained in access profiles and assign those access profiles the the lifecycle state. Any access assigned in those access profiles will remain. The downside to this is that if anyone did not already have that access, they will gain it once they enter that lifecycle state.

A more granular approach is to follow what others have said and use workflows. Workflows can remove access for specific sources and can be triggered by lifecycle state change.