Sticky entitlement

Hi,
As part of leavers, we assign an access profile to trigger the before provisioning rule. In Before provisioning rule for AD we are trying to remove all the AD entitlements.

Scenario1
User does not have entitlement that was granted as part of access request from IDN. Before provisioning works fine and it removes all entitlements.

Scenario2
User have entitlement that was granted as part of access request from IDN. Before provisioning works fine and it removes all entitlements. However after running the AD aggregation and identity refresh the entitlements assigned via the access request is getting assigned back.
I have seen this similar sticky entitlement issue in Sailpoint IdentityIQ.
https://community.sailpoint.com/t5/IdentityIQ-Wiki/What-s-sticky-AttributeAssignment-and-how-to-delete-it/ta-p/194560

Question: Do we have sticky entitlement or Access profile in IDN?

Thanks,
Srimathi

@colin_mckibben , Is Sticky entitlement issue there in IdentityNow as well?

It is there if you use “Roles” in request centre but if you use “Applications” in request centre you would not see this issue.
Roles are refreshed as part of scheduled refresh but applications are not. Though you can only have one source under application and cannot combine access from different sources like roles.

I’m not quite sure that it happens only if “Roles” are used.
We have some very troublesome situations in our tenants related to those “Sticky Entitlements” for SCIM Sources.

Scenario:

  • Entitlement was granted as part of IdN Access Request. The request was made for requestable entitlement so not linked to the specific application.
  • Later in time, these permissions were deleted on the source side. After entitlement aggregation, it was also deleted from IdN.
  • From now on, IdN is constantly trying to reassign this deleted entitlement to users that have it before it was removed as permission on the source side.

This is very very troublesome behavior. Is there any way to control/disable this ‘automatic reassignment’?

This should be looked by support. Deletion of entitlement has always been somewhat tricky considering entitlements come from 2 different aggregation dataset. There was change made in past to consider entitlement aggregation as source of truth even though they are coming from account aggregation.