We have entitlements aggregated from JDBC and web services connector type sources. These entitlements are requestable, and post approvals entitlements are being assigned to the identities.
However, in few scenarios the disabled accounts wouldn’t be aggregated from the target applications. In that case, IDN is trying to assign back those entitlements that were granted via access request.
Is there a way to remove these entitlements granted via request while disabling the account on target system? Also, in our tenant workflows feature is not available.
I guess the entitlements are removed at Target side once account is disabled. That is why the same entitlements are getting assigned back.
How are you performing disable operation ?
From SailPoint side or from Target ?
If you are doing it from SailPoint side then you can add customization in Before Provisioning Rule to remove all the user entitlements in that respective source along with disable operation.
For web services type connector, we are removing the entitlements using before operation rule which is attached to disable operation. During next aggregation the disabled account wouldn’t be available.
Is there any alternative other than before provisioning rule?
This seems like you are using requestable roles. When you use roles in request centre it has disadvantage of being sticky. You can use access profiles and application combination if that meets your requirement and if sticky roles are your problem.
Another solution you can implement is remove all roles on termination through workflow but you do not have workflow available in your tenant so this is not the solution you can utilise but this is quite common use case for workflows.
We have made entitlements as requestable not the roles. These entitlements can requested from Request Center. However, once the user is terminated these entitlements are being removed even though if we try to remove them on target application using JDBC provisioning rule or web services before operation rules while disabling the account. On the IdentityNow side, during the next aggregation IDN is again triggering the provisioning events and assigning those entitlements back to the user.
Could you please suggest any possible solution to permanently remove these sticky entitlements without using workflows or before provisioning rule?
One way is to have a BeforeProvisioningRule which would would also remove the stickiness of Entitlements provisioned through Request Center
or as @chirag_patel suggested you could create Access Profile for those entitlements and then make them requestable through Application. If an Application be requested then the Entitlements provisioned aren’t sticky.
Also, there is one section in IDN web services connector guide which says “Remove Entitlements When Disabling Accounts” but not sure how to or where to add the below part:
Thanks for sharing the blogs. However, in our tenant workflows feature is not subscribed. Also, could you please let me if this is expected behavior or bug in SailPoint IdentityNow. Because as far as I remember this sticky entitlements behavior is only observed for Roles that were requested from IDN’s Request Center.
Honestly, I am not entirely sure if this would be considered a defect or not. Your best bet is to submit a ticket to our support team so they can confirm the expected out of the box behavior and determine if a defect is at play.
Can this stickiness be removed froma BeforeOperation rule as well? What is what needs to be done to remove it? is it about setting “assignment” = false in the AttributeRequest?
We use certification campaigns to remove access for job changes or system off-boarding. Please let me know if you’d like more specific information or have an example use case I can comment on.
I don’t have a Before Provisioning Rule, I was considering doing it on the Before Operation Rule for the Add Entitlement operation. Or maybe remove the just assigned access on the After Operation Rule for Add Entitlement
My case is kind of particular, because I’m marking as requestable groups that are of type “RoleAPIGroup” which has more entitlements and more properties per entitlement than regular “Groups”, which once provisioned become regular Group objects, so by the time Identity Refresh runs, the “RoleAPIGroups” cease to exist in the Account, but IdentityNow is still looking to provision them back.
Because of this I could maybe remove the “RoleAPIGroup” objects on an After Operation Rule.
Another approach I thought about was, get the ProvisioningPlan, which has the Accounts, which then have the AttributeRequest. This carries an “args” object which has the “assigment=true” property.
Then remove the “assign” property from the “args” object, and rewrite it into the AttributeRequest, to then replace it on the AccountRequest which then could be updated on the ProvisioningPlan and let it continue.
The issue I think with your approach is that you will be able to query the provisioning plan in the Before/After Operation Rule but won’t be able to modify the plan itself.
The output for After Operation is updatedAccountOrGroupList while for Before Operation is EndPoint / Map.
However, with that being said I could be wrong. Please let me know if you find otherwise.