SailPoint will continue to add entitlements that were requested via request center to identities in every Identity Refresh / Manual processing. SailPoint would try to re-add the entitlements or even create the account if the account doesn’t exist for the user.
Diagnosis
SailPoint entitlements are sticky in nature, Once an entitlement has been assigned to an identity using access requests, it will be provisioned to the identity’s source account. If the entitlement is directly removed from the account on the source, it will be reprovisioned to the account at the next aggregation.
If the account is deleted on the source, such as Active Directory, it is recreated along with the requested entitlement upon the next refresh.
Solution
Create Access Profiles instead of making entitlements as requestable. Knowing the fact doing all entitlements in this manner is not feasible if we have hundreds of thousands. If we have thousands of Access Profiles to be created SailPoint provides a utility to create bulk Access Profiles, which will ease a lot. Reference: IdentityNow Bulk Access Profile and Role Importer - Compass (sailpoint.com)
If we still want to go with requestable entitlements then we will have to make sure the requested entitlement is removed from SailPoint IdentityNow before deleting the account. That can be achieved via any of the following approach:
Using Access Certification.
Revoke it by submitting an API call.
Can make use of workflows.
Manager revokes the access manually from SailPoint UI.
Using Before Provisioning Rule - remove all the access before disabling / deleting the account.
I’m getting mixed responses on something that I’d like to clarify and make abundantly clear:
Are entitlements ONLY sticky IF they were requested via Access Request?
If so, does that mean entitlements that were granted as part of an Access Profile (via Request Center) are NOT sticky? The idea being that since the entitlements were assigned as part of the Access Profile definition (and not directly via Access Request), then they aren’t sticky.
On the topic of revoking entitlements with a Before Provisioning Operation rule: Are we saying that if I have the Identity Profile setup to disable access when someone flips to Inactive lifecycle state, that Sailpoint WON’T revoke entitlements AND disable the user as part of that? Will it simply Disable, and the next time the various sources aggregate they will re-enable the user because entitlements weren’t revoked as part of that LifeCycle State Change?
Question: Are entitlements ONLY sticky IF they were requested via Access Request? Answer: Yes, as per my observation and testing entitlements ONLY sticky IF they were requested via Access Request. I did not test it via API, But if you read the Idea GOV-I-3745 they mentioned its via API or Request Center.
Question: Does that mean entitlements that were granted as part of an Access Profile (via Request Center) are NOT sticky? Answer: Yes, as per my observation and testing Access Profiles requested via Request Center were not sticky.
Question: Are we saying that if I have the Identity Profile setup to disable access when someone flips to Inactive lifecycle state, that Sailpoint WON’T revoke entitlements AND disable the user as part of that? Will it simply Disable, and the next time the various sources aggregate they will re-enable the user because entitlements weren’t revoked as part of that LifeCycle State Change? Answer: SailPoint wont revoke the access via inactive LCS we do not have that option there, It will just disable the account if you configure so.
Coming to re-enable of account, No it wont enable the account if the account was disabled.
@shekhardas1825 : Below is our observation. Can you please comment on this outcome:
Birthright Roles: Entitlements will be automatically reassigned during identity refresh.
Access Request based Roles: Entitlements will be assigned only during access request. Entitlement changes made at source level will not be updated back to identities during identity refresh.