I would also like vote up the search filter/options in My Access mentioned earlier. I’d also like to add the Admin Identities view to that. Our users will now be able to revoke entitlements from My Access, but there is still no way for them to search, sort, or filter these to find the entitlement they wish to remove. We have users with hundreds of entitlements, and they will basically need to click and scroll through each page to find the one they need to revoke. The My Team view has a search bar and including that in these other pages would greatly improve end user experience.
1 Like
Feedback on New Feature: Self-Revoke Entitlements in Identity Security Cloud
Thank you for introducing the new feature in Identity Security Cloud that allows users to self-revoke entitlements, access profiles, and roles, alongside managers having the capability to revoke the same for their team members. While this feature offers flexibility and autonomy, there are several concerns regarding its implementation and potential impact on our environment:
- Unrestricted Revocation of AD Entitlements:
- We have numerous Active Directory entitlements designed to block users from accessing certain resources. The ability for users to revoke these entitlements independently could lead to unintended access without oversight.
- Implementing approval processes for revocations is not a viable solution, as it would disrupt the functionality of our scripts designed to handle Segregation of Duties (SoD) policy violations. These scripts need to operate without manual intervention to ensure compliance and efficiency.
- Impact on Access Profiles:
- Users can currently revoke individual entitlements within an Access Profile, resulting in the removal of the entire Access Profile from their account. However, this does not necessarily remove all bundled entitlements, leading to inconsistencies and potential security gaps.
- For Access Profiles with a sunset date, revoking a single entitlement causes the Access Profile to disappear from the user profile, potentially preventing the removal of related entitlements at the designated sunset date.
- Lack of Global Controls:
- Our access catalog is structured around requesting Access Profiles or Roles. Allowing users to revoke entitlements that are not requestable introduces a lack of control at a global level, which could compromise the integrity of our access management system.
Recommendations:
- Global Settings for Revokes:
- Implement global settings for revokes specifically on entitlements, similar to the ‘Enable Entitlement Requests’ setting. Create options such as ‘Enable Entitlement Revokes’ that impact only non-admin users. This approach would allow users to revoke only Access Profiles or Roles curated by the ISC admin team while enabling admins to revoke entitlements from users for security and SoD purposes.
- Restrict Self-Revocation for Critical Entitlements:
- Consider implementing a mechanism to restrict self-revocation capabilities for critical entitlements, especially those tied to security policies or resource access restrictions.
- Ensure Consistency in Access Profile Structure:
- Develop a system to ensure that revoking individual entitlements within Access Profiles does not disrupt the intended structure and functionality of these profiles, particularly concerning sunset dates.
- Establish Global Controls:
- Explore options to establish global controls or permissions that can be applied across the feature to maintain consistency with our existing access management framework.
Overall, while the feature has the potential to enhance user autonomy, its current configuration poses significant risks that need to be addressed to prevent security breaches and ensure seamless integration with our existing workflows.
3 Likes
Strongly agree with all your points Alex. Looking forward a response from SailPoint on it. Though it provides ability for End users and other to request removal of access; however it will increase operational challenges and risk if not configured properly. Access profiles with multiple entitlements is one part. Organizations needs to a solid role model implementation to avoid such issues, also understanding by end users. Global settings and restriction (specially for critical access/AD groups) mechanism at granular level is very much required which can be controlled by ISC admins with better visibility of logs under search & reporting.
Important Update
In light of some of the concerns you have voiced, we are going to hold back the entitlement revocation functionality (i.e. in the My Access, My Team, and Identity > Access UIs) for another 2 weeks.
This week’s rollout will still include:
- self-revocation of roles and access profiles
- the access revoker user level
- revocation of roles and access profiles by admins and access revokers
- approval configs for entitlement revocation (at global, source, and per-entitlement levels)
Over the next 2 weeks, we encourage you to implement the approval controls you need for entitlement revocation, so that informed approvers can deny requests to revoke entitlements that should not be revoked. Then, during the week of May 19, we will roll out entitlement revocation by self, manager, revoker, and admin.
We will continue to investigate further enhancements that may be needed (such as configurations around revocability per item or around revocation by self). In the meantime, this approval config should be used to address the security requirements around the set of entitlements that need it while allowing us to support the broader customer need, which we have heard consistently for a while, for self-revocation and revocation across all access types.
3 Likes
A couple of notes here to address outstanding questions:
-
Entitlement request status: In all of my testing (and in testing I did with @angelo_mekenkamp last week), I have observed that the default for newly aggregated entitlements is not requestable. It is possible that some connectors might behave differently, but at this time, I am not aware of that being the case. Therefore, customers who want to have entitlements be not requestable but still be revocable can globally enable entitlement requests but individually leave them not requestable to achieve that behavior. As a safeguard, you can enable a global approval config for entitlement requests that would allow an admin (or other) to deny the request if one did get marked as requestable.
-
Dated AP Assignments: I am currently testing the behavior of requesting an access profile with an end date and then revoking an entitlement out from under it, to see if the future-dated revocation will still revoke other entitlements in that access profile. I should be able to report back here tomorrow with that answer, and we will consider any adjustments we might have to make for security purposes if that does not still enforce the end date like I believe it will.
2 Likes
Thank you @jennifer_mitchell! Happy to see this being released in parts as it allows us to put the right security controls in place before the new functionality goes into effect 
Update re: dated AP assignments:
I am happy to report that when a user has an access profile assigned with an expiration date and revokes an entitlement out from under it, the scheduled revocation of the access profile assignment is retained and any other access that is part of the AP is revoked at the scheduled time. I get that there is a visibility gap in the way this is tracked and reflected in the UI, but there is not a security loophole for users to exploit here.
If you’d like to test this on your own to check my work , this is what I did:
- Defined an access profile containing 2 entitlements and made it requestable.
- Requested that AP for a user, specifying an expiration date (of the following day for a short test; you could also use the API to request it with a time for an even shorter test); approved and provisioned.
- Requested revocation of one of the 2 entitlements from that user; approved and (de)provisioned.
- Waited until the end date arrived. Checked the identity and observed that remaining entitlement had been revoked. (Behind the scenes, while I waited, I was able to see a representation of the identity that showed the scheduled end date for the AP still recorded, so this was a result I expected.)
2 Likes
We appreciate SailPoint’s efforts to enhance the Identity Security Cloud (ISC) product with new features based on customer feedback. However, as we prepare for the introduction of the Access Revocation feature, we have concerns about its implementation, particularly the flexibility it offers users to self-revoke entitlements, roles, and access profiles.
Our primary concern revolves around the potential for unintended access changes, particularly related to Active Directory (AD) groups used for user classification. In some cases, users are added to groups to enforce restrictions or limitations based on their classification. Allowing users the ability to independently remove themselves from these groups could inadvertently lift critical security restrictions, posing compliance risks and exposing organizations to potential legal repercussions.
Given legal obligations to maintain these downstream limitations, any lapses in applying these restrictions could result in severe consequences, including audit findings and possible fines from regulatory bodies.
To address these concerns, we suggest the following enhancements for consideration:
- Introducing Fine-Grained Access Controls: Implement more granular access controls to manage requests effectively. This includes user-level permissions for:
- Request Role
- Request Role Removal
- Request Access Profile
- Request Access Profile Removal
- Request Entitlement
- Request Entitlement Removal
These controls would allow organizations to tailor access management more precisely according to specific roles and responsibilities within the organization.
- Entitlement-Specific Restrictions: Provide the ability to set “allow request to remove” settings across roles, access profiles, and entitlements. This would ensure that administrators can control which elements users are allowed to request for removal, adding an extra layer of security.
Although the recommendation is to “implement the approval controls we need for entitlement revocation”, the current product lacks the required level of control we would require. Additional features must be provided before we can accept the update to our tenant.
First of all thanks for the detailed explanations on all the points.
We are testing this out and observed one issue regarding revoke entitlement workflow.
We have followed below steps:
- Enabled Entitlement Requests feature from System Features
- Configured Approvers as Entitlement Owner (Is this for Add & Revoke requests both)
- In Access Model → Entitlements, edit the entitlement, enable access Requests. But this doesn’t have any options to configure approvals for Revoke Requests.
So, how to configure approvals for remove entitlement operations.
With approvals configured at global level, we tried revoke entitlement requests but it is not going for any approvals.
Can you please clarify.
@maheshtare
If your tenant has any of the revocation approval config options available in your UI pages (global or per-entitlement), they should be applied when revocation is requested, so if they are not, please open a support ticket.
Likewise, if you are seeing the global config for revocation approval in your UI but are not seeing the per-entitlement revocation approval config, the team should check your tenant’s enabled feature flags to see if there is a discrepancy.
If this is your prod tenant and none of these revocation approval configs appear, it may be that we haven’t enabled it for you yet. The production rollout is happening throughout this week.
Any documentation released yet?
Updates to our documentation went out yesterday afternoon. The content is interspersed into the appropriate sections of admin and user docs.
I noticed the following:
Created access profile pointing to entitlement A,
Created role pointing to entitlement A directly, not referring to access profile.
Requested role, received entitlement and role.
Now went to My Access, and saw the access profile under there (which is there as detected access profile), I was able to hit revoke. Under My Requests I saw it is successfully removed, but when I went to My Access again, I saw it still being there.
So it is worth to note that even though some access profiles do not have the revoke button because you can’t revoke them since the access profile is part of a role you might have, there are still examples of access profiles that are not really revocable that still contains the revoke button.
If all entitlements underneath an access profile are part of roles you have, without these roles pointing to the access profile, you do see the option to revoke the access profile, but you are not able to actually get rid of it.
That makes sense - this is an overlapping access scenario in your role/AP model. As you note, we don’t have a record of the AP being connected to the role (because it isn’t, directly), so we don’t detect the relationship up front, but during the attempt at revocation, we see that the underlying access (in this case, in its entirety) is required by a separate role assignment, so we can’t revoke it. The end result is appropriate, even if there could be confusion in the experience of being allowed to request a revocation that can’t actually be fulfilled.
That said, if it turns out that this access model usage/scenario is a common one, we should revisit how we reflect an access profile’s revocability.
1 Like
The documentation says the following in this section:
“We’ve also introduced a new user level that grants users the authority to submit revocation requests for anyone so you can authorize people who are neither the user nor their manager to manage revocations for your teams.”
However, from what I understand, a user with this user lever could revoke access for any other user within the environment, not just users on their team, correct?
Another issue I didn’t understand is about entitlement revocation, which will be launched next week.
Even if an entitlement is not marked as being requested, will the user be able to request its revocation on their own?
@raibom
Users with the access revoker user level will be able to revoke for any user. Sorry if that came across less than clear. We intentionally said “for your teams” meaning “for your personnel” rather than “for their team”, as it’s not limited that way.
And for your other question, yes, any entitlement can be revoked, not just requestable entitlements. We are providing the time to set up an approval config to protect entitlements you need to block from revocation, but we didn’t want to block non-requestable entitlements from being revoked because there are valid use cases for wanting to allow revocation when you might not allow new requests for an entitlement (e.g., one that existing users have been grandfathered into but that is no longer allowed for requesting.)
1 Like
Thanks for the explanation @jennifer_mitchell ,
Would this new option that we will have in the entitlement configuration be to not allow self-revocation? If so, I believe that would solve the problem, but it is important that this checkbox is checked by default for all entitlements and also for the creation of new ones.
Regarding this argument that entitlements that cannot be requested can be revoked, I believe that the most appropriate thing for this case would be to open a certification campaign for the specific entitlement, the point here would be self-revocation by the user himself.
There are cases of systems where, due to internal policies, users gain certain rights by default, which end up being imported during aggregation. Allowing the user to revoke these rights can cause many unmapped problems in the use of the system.
May we know when the User Level Access Matrix will be updated to include the “Access revoker” user level details?
Access Revoker is documented here: User Level Permissions - SailPoint Identity Services
We have tried to weigh the value of adding new levels to the Matrix grid against the UX complexity of scrolling left-right as well as up-down in presenting that grid, and we have selected a path where users levels that are likely to be compared to each other (i.e. to choose which level to assign) are shown in the grid whereas user levels that are narrowly targeted in permissions (like access revoker, access request admin) are being documented but not added to the matrix.