Managing single valued entitlement

Identity Security Cloud (ISC) ISC Discussion and Questions
1

We have an application integrated with ISC that supports only 1 entitlement at a time for a user. If a user requests entitlement E1, ISC provisions E1 and this is fine. But when the same user requests entitlement E2, ISC provisions E2 and then E1 again and then E2 and it keeps on doing that a few times. Every time the identity refreshes, the same thing happens. The behaviour is same if we make entitlement requestable or add the entitlement to a role and make the role requestable. I haven’t tested with access profile yet but my understanding is it would be the same behaviour.

This behaviour is expected because from ISC perspective, user requested for the entitlement/role and when it sees that the user doesn’t have that access on the application, it tries to provision it. (This might be because of a concept similar to attributeAssignments and roleAssignments that IIQ has).

I am looking for recommendations on how to manage this scenario. One option we have looked at is defining a workflow that triggers at every access request approval, and if the requested access is one of these entitlements, the workflow checks if the user already has an entitlement from the application and removes it.

Defining SoD policies wasn’t useful as it doesn’t help with automatic removal of ‘conflicting’ access.

Are there any recommendations if you have encountered the same issue before?

Thanks in advance.

2

Hi @asaxena

A good solution to your single valued entitlement would be to use Access Profiles for Access Requests.

Access Profiles for Access Requests - As per this post on entitlement stickiness, APs assigned via access requests should not be sticky and will not reassign on the access being deprovisioned.

Hope this helps!

3

Thanks @ksbagade . I should have tried out using access profiles instead of just assuming! This helps a lot.

4

In SailPoint Identity Security Cloud this behavior occurs because entitlements are modeled as additive access, so when the application only supports a single entitlement ISC repeatedly tries to remediate the missing previously granted access during identity refresh. The recommended approach is to model the access as a single account attribute with multiple values (E1/E2) and configure provisioning to replace the value instead of adding entitlements. If redesigning the entitlement model is not possible, implement a post-approval workflow to remove the existing entitlement before provisioning the new one to avoid the remediation loop.

5

A couple of contracts ago, I ran into a problem with deliminated sources where users if users were given two entitlements in the source, ISC used to only hold one of them. This occurred because ‘Entitlements’ was not set as ‘multi-valued’ in the schema

image
image1578×113 6.84 KB

Have you tried amending the schema to remove the multi-valued feature and then observing what happens when you try the access requests?

6

@asaxena I’m glad you were able to resolve your issue :slightly_smiling_face:

If my response was helpful, please mark it as the solution for the thread.

7

Hi @asaxena

Can you please confirm what type of application is it ? If it is web service based application, then the issue could be that the API is replacing the entitlements instead of adding it. Or in back-end the assignments are correct ?

Thank You.
Regards

Vikas

8

Have you tried wrapping the entitlements in Access Profiles instead of making them directly requestable? Since Access Profiles assigned via access requests are not sticky, ISC won’t keep trying to re-provision the old entitlement during identity refresh.

9

Hi @phil_awlings yes the entitlement attribute is not marked as multi valued and the behaviour is what I have described above.