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.
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
So is this rule works for all connector?
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.
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
Yes, only for those sources where entitlement removal is required in conjunction with account disablement.
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.
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
@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.
Hi @Amsingh1 ,
It would be the entitlement attribute name that is specified in the account schema.
Thanks,
Liam
Currently, Remove All Access in lifecycle state affects all sources. To selectively remove entitlements for specific sources, you have two options:
-
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.
-
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.
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.
ācloudServicesIDNSetupā: {
"eventConfigurations": \[
{
"eventActions": \[
{
"Action": "RemoveEntitlements",
"Attribute": "Roles",
"Value": null
}
\],
"Identity Attribute Triggers": \[
{
"Attribute": "cloudLifecycleState",
"Value": "terminated",
"Operation": "eq"
}
\],
"Operation": "Disable"
}
\]
},
I used this but the role is not getting removed
@amandeepsingh7 There seems to be issue with the code āthe backslash (\ )should not be there. remove (\) and try
Hi Sagar these backslash are not there, it got added when i added the code here in the forum
@Amsingh1 Okay then double check your LCS value is correct āterminatedā or its āterminateā and RemoveEntitlements account schema attribute is āRolesā only.