I am onboarding a third-party application using Web services connector in SailPoint IdentityNow. I have configured 3 HTTP operations Account aggregation, Create account (with ‘Ent" flag enabled) and Delete account. All operations are working fine but during the Disable operation, I found these “Add entitlement” and "Modify Account’ events followed by the "Disable Account’ triggered. I haven’t configured any Add/modify operations defined after Disable operation. I don’t have any before provisioning rule for this application. Why is it occurring? What am I missing here?
Create account request body with “title” as entitlement:
{
“firstName”: “$plan.firstName$”,
“lastName”: “$plan.lastName$”,
“email”: “$plan.email$”,
“title”: “$plan.titleId$”,
“phone”: “$plan.phone$”,
…
…
…
}
Delete account:
Trigger Delete HTTP operation during the “Disable account” operation type.
Due to the stickiness of entitlements, ISC will try to re-add the entitlement back if it was not originally removed through any of the methods mentioned above.
This means that if the account itself got deleted in the first place, ISC would create the account first and then add the entitlement.
Creating access profiles is one way of overcoming the problem or you can make use of WF’s to remove entitlements.
Hi @jesvin90 ,
Thanks for the note on Sticky entitlement. I tried using Access profiles, and it is working as expected during provisioning and de-provisioning. However, in my case, I can request either a Role with Entitlement or Direct entitlement. According to our automation criteria, the direct entitlement option is no longer available. So, the only option now is “Role.”
Here is the Role with Entitlement criteria: I have created a role with:
“Application Entitlement” (Example: Adobe Standard) in “Manage Access”
Assignment criteria as “Type - Entitlement,” “Source - Active Directory,” “Entitlement - Adobe_std_AD_group”
Identity status - Active
In this scenario, how can I remove the entitlement (Adobe_std_AD_group) tied to this user before or after disable? Are there any other ways to handle this? If Workflow is a good option, please share any documentation to refer to.
How did you revoke the requested access items before disable account operation?
- I havent revoke the entitlement as the application doesnt support remove entitlement/Disable operation. It supports only DELETE operation
Whether the requested access item is a Role or a direct Entitlement?
- Role
I am not sure whether I’m missing something here, because on your earlier comment you said there is no birthright roles, but in the latest response I can see the role is configured with membership criteria which obviously considered as birthright role to the identities who is matching with the criteria. Considering that you have a birthright role, you can try the below options
Add another criteria to unassing this role from identities to remove the entitlement during delete process. This may be an attribute which decides the delete operation.
Attach the Access Profile to the role instead of direct Entitlement which I can see you already tried and its working.
Check whether this issue occurs to all identities or intermittent, if it is intermittent, check the aggregation schedule and there might be a chance the accounts are deleted before the role revocation completed.
If you are making use of request center or API to grant entitlements directly to users, you can consider making use of certifications (auto created through WF’s) or this sample WF for entitlement revoke and then trigger the disable/delete operation through the same WF.
If you are assigning entitlements only through roles, entitlement revokes can happen automatically during user terminations, if you are checking the user status in the membership criteria.
