When a user is automatically assigned to a role and they are no longer eligible for the role, should the entitlements that are directly assigned to the role be removed from the user?
We know that when a user no longer meets the role criteria and they are removed from a role, the access profiles associated with the role are removed.
We also know that when a user is changed and meets the criteria for a role, they are automatically granted all of the access profiles and entitlements associated with the role.
We had assumed that entitlements would be removed from a user if they no longer met the assignment criteria for the role, but that does not seem to be the case for an example we encountered in our environment. Additionally, the documentation might suggest this is intended behavior, so we are just trying to answer the initial question to determine if this is a bug or if this is expected behavior.
The first paragraph states, " Users often need to be given access based on attributes like their job title, department, or location. You can configure assignment criteria to automatically grant a role to users who should have it. This also provisions the entitlements in the role’s access profiles to each user’s source accounts." So access profiles and entitlements are provisioned when a use meets the assignment criteria.
However the next paragraph states this, " Additionally, when a user no longer meets the criteria, Identity Security Cloud deprovisions the role and its associated access profiles. This can occur because the assignment criteria or the identity data changed." Is this saying that only the access profiles are removed, implying the entitlements associated directly with the role are not removed? Or is this an oversight in the documentation, since there is not explicit mention of entitlements not being removed, and entitlements not being removed is a bug.
The access profiles and the entitlements associated with the access profiles are expected to be removed when a user no longer satisfies the role condition.
Logically, an access profile is just a combination of entitlements. If a user contains all the entitlements that are in an AP, then the user implicitly gets the access profile. So removing the AP and not the entitlements does not make sense.
Have you checked if the entitlements that you see not getting removed were provisioned through an access request or through LCS.? They may be enforced in either case.
Totally agree that it wouldn’t make sense. We are going to do some more testing to recreate this scenario to see if it happens again.
The access not getting remove is not requestable and it is not part of any LCS so the only way a user could get the access is either through a role or native provisioning. We checked the access history and event logs and could see that the role was removed from the user, but there was no remove entitlement action generated even though the user still had the group (both in IDN and on the native AD source).
Is this occurring for all users or just some users? If it is some users, I would look at whether ISC provisioned the role/access profile or if it is possible that the entitlements existing on the user prior to ISC? If the user had the entitlements prior to ISC, they would still get the role because of the membership criteria/request and the access profiles but they wouldn’t need to have the entitlement actually provisioned as it already existed.
I had done some testing on this at one point and I think I saw different behavior when ISC provisioned the access or the entitlement already existed for that user.
This particular role doesn’t change membership that often and we just implemented it last month so I can’t easily see if it happens to all users or just some. However I did get some additional information based off your comments. This user had the access before the role was created. We were just trying to make this access automatically assigned to the rest of the group of users so when the role was initially created, this user was just assigned to the role but didn’t have the access added since they already had it on their account.
If I am understanding your post correctly, you are saying you have seen issues with Roles removing access from users if the user had the access before the role was created? The user definitely didn’t have the access prior to ISC as we have been running it for a few years now and both the group and user are relatively new, but perhaps because they had the access before the Role was created is what is causing this issue.
This would obviously not be the ideal behavior and I am curious if you have seen something like this also (or if anybody else has).
Hey, @zachm117! Sorry this may not be much help, but I’d perform some testing in sandbox and open a case for this if you can replicate. I’m not in the position to do so now (or I would do it for you and verify!) but in the past couple months since SailPoint included entitlements in roles (this was released in February IIRC), I’ve seen some buggy behavior for both provisioning and deprovisioning of those directly assigned entitlements. Access profiles have continued to work as expected.
At the end of the day, I believe the documentation you linked above is just out of date. I say this because it doesn’t seem to speak about access profiles and entitlements separately, as it should. It speaks about entitlements within access profiles, and then only about access profiles. So my guess is the documentation needs to be updated to reflect the February feature enhancement and you’re dealing with a bug.
This is working as designed.
Let me give you a context of what use case is this satisfying, if any identity has entitlement directly assigned from a source which means that no matter if that entitlement is now a part of a ROLE or Access Profile assigned to that identity. It still keeps it as it was assigned by the virtue of detection from source and not assigned via ROLE or AP.
So, in simple terms LCS change or not meeting ROLE criteria will only remove the accesses i.e. ROLES or AP and their underlying entitlements only if they were assigned to that Identity by the virtue of assignment of that respective Role or AP.
This same logic applies beyond entitlements, also to AP where they are also detected and if they are detected then LCS changes wont remove those AP’s.
You can refer this to deeper understand how Roles & AP will act based on certain transactions, beyond what I mentioned above.
Are you sure that is how the entitlement removal inside a Role works.?
As far as I have seen, even if the entitlements are assigned directly in the target system, if the user meets the role criteria and then later fails the criteria, all the entitlements part of the role are expected to be removed for the user.
If the entitlement removal does not work that way, how can ISC be incorporated into an existing target (AD for example) in an organization.? As per your explanation, only the ones assigned through the roles by ISC will be removed once the user fails to meet the criteria, which means the entitlement removal through roles will not work for the existing users. That would defeat the whole purpose of Role automation.
It does not defeat the objective of Automation, if something is not assigned to identity by the virtue of the automation i.e. Criteria based roles or LCS change, then those things wont respect if they stop matching criteria or LCS changes.
Even in certifications you can find them as a separate access rather than encapsulated as those entitlements were not assigned due to any role matching or LCS change.
IDN has to respect what is given directly by the source, it ensures that what was given directly from the source should not be hampered by the flouted Identity Model if you expect them to be removed on not matching. If so this indicates that that identity has that access wrongly assigned outside of IDN too.
Roles which are assigned using assignment criteria either it has used access profile or entitlement approach to assign access they should be removed if the assignment criteria is not matching anymore.
I think the documentation is not updated after SailPoint has allowed to choose entitlements in roles.
We have this use case to assign the access using entitlement approach. We could see that the entitlement (group) is de-provisioned once the role is removed from the identity.
@jesvin90 I agree with you as well. Even though the access is assigned in the target system directly. Once the role assignmet is not met ISC will remove the access. I have validated this quickly and able to see that the group which is assigned directly in the target is de-provisioned when the role is unassigned.
@harshamin9 Can you share if there is any documentation on this behaviour from SailPoint. During my validation I could see the group is removed when the assignment criteria is not met.
I am checking internally, I dont expect them to change the legacy behaviour I mentioned above.
I will keep you posted once I have a definite answer of did we deliberately changed to satisfy some more important use case or this was a miss while allowing entitlements to be part of Role directly.
Sorry for the delay, I was OOO for the past few days. I haven’t had a chance to test this, but I would like to try to since our observations is that access that the user previously had before the role was created, was not removed when the role was removed. @harshamin9 you mentioned this is expected, but there seems to be some confusion if this is still the case or not. I’ll wait for your confirmation on what the expected behavior is currently.
However, if this is the expected behavior, I am not really sure what the best way for us to manage this is or really why this is the case. If we are deploying ISC or onboarding “new” applications into ISC that users already have access to, then we would essentially never be able to role base the access for these systems and have the deprovisioning work for roles created for these sources without removing the access and having the roles grant it back.
Additionally, I am not really sure how we would ever know if the access is fully role controlled or not. It seems like a reasonable assumption that if a user has Role1, which provisions Entitlement1, and the user has Entitlement1, that entitlement is controlled by the Role. How could we tell if the access is being managed by the role, or if the access was provisioned before the role was created?
This also seems like inconsistent behavior with the way Access Profiles work. If a user is given an entitlement directly on a source and there is a corresponding Access Profile for that entitlement, users inherit the Access Profile. If the Access Profile is then revoked, then the entitlement is removed. So if users can inherit Access Profiles and those inherited Access Profiles can remove access when revoked, why would the same not be true for Roles if they no longer meet the assignment criteria for a role and thus should lose the access?
Hello @zachm117
I confirmed and looks like we changed the behaviour about a year back. Earlier it was taking entitlement assigned via source into account while de-provisioning, but now it will remove all the accesses irrespective if they are assigned via source or not.
So, the dilemma to know what will get unassigned is now cleared.
Apologies missed to get back to you.
