Enhancement: Access Revocation!

[jennifer_mitchell]

Description

Access Revocation just got a lot more accessible in Identity Security Cloud!

With this release, we’re introducing self-service access revocation, a new Access Revoker user level to designate users who can submit revocation requests on behalf of anyone, an entitlement-revocation approval configuration option, and expanded revocation functionality for managers to include entitlements.

New Capabilities

End users can now revoke their own access through the My Access page when they no longer need it, allowing them to support your organization’s least privilege goals (or at least let go of access that conflicts with new access they need to request!).

Managers can now revoke individual entitlements held by their direct reports, in addition to roles and access profiles.

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.

And finally, administrators can configure approval requirements for any entitlement revocation request, matching the options that already exist for roles and access profiles. This allows knowledgeable authorities to help prevent errors or accidental revocations.

Note: The basic rules of Identity Security Cloud access management still apply - only requested roles (not auto-assigned ones) and entitlements that exist outside of roles and access profiles will be revocable.

Who is affected?

This is being rolled out to all customers.

Action Required

Administrators are encouraged to set up entitlement revocation approval requirements, to enforce the desired security around that revocation flow. You can set your entitlement revocation approval requirements globally (Admin > Global > System Settings > System Features), per source (via API), or per individual entitlement (Admin > Access Model > Entitlements > Action: Edit > Access Requests).

To designate the users who can revoke for others in your org, you’ll need to add the Access Revoker user level to their identities. Navigate to Admin > Identity Management > Identities, choose an identity, and then use the Actions menu to choose Set User Levels and select Access Revoker.

No special actions are required to enable manager and self-revocation. All users can request their own revocations and all managers can revoke for their teams.

Usage Details

To revoke their own access, users will navigate to My Access, choose an access tab (Roles, Entitlements, Access Profiles), then locate and select the item they want to revoke to view its assignment details.

For roles and entitlements where users may have multiple assignments, an overlay displays item details along with a list of the user’s assignments. From there, they can open the Assignments tab, verify the account details to ensure they’re revoking the correct one, and then select Revoke Assignment.

Because access profiles can only be assigned once per identity, the access profile flow is a little simpler, displaying the item details in an overlay that includes a revoke option if the assignment is revocable.

The same UX flows apply for Manager revocation and Access Revoker, but through different UI paths:

• Managers access their direct reports’ assignments through the My Team page.
• Access Revokers access users’ assignments through Admin > Identity Management > Identities > select an identity > Access.

Important Dates

Sandbox rollout: week of April 28

Production rollout: week of May 5

By RSVP’ing to this event you will be reminded of this release prior.

[BenNelson]

Does this also have the multi-account access revoke functionality or is that a separate release?

[TheOneAMSheriff (Amar Sheriff)]

Hi @jennifer_mitchell,

Awesome announcement, really excited to finally have this feature in production. Kudos!

[jennifer_mitchell]

Hi @BenNelson
This will include multi-account access revoke functionality. That’s supported by the Assignment 1, 2 experience you see in the Usage Details description.

[BenNelson]

Thank you. I just wanted to confirm that because we have been eagerly awaiting that functionality

[angelo_mekenkamp]

Great stuff @jennifer_mitchell!

I am definitely looking forward to try out this functionality and see how we can best configure this to meet our needs!

3+ years ago, I created this idea for self service access revocation requests in the idea portal and because it is on the first page if you sort by number of votes, I am sure that many others are also looking forward to this functionality!

Since access request management is one of the most important modules of ISC and the devil is in the details, we need to understand in depth what it can and can not do. Hence, I have many questions/remarks from my side

1. There is a difference between directly granting access (admins can do this for example by adding identities to the membership criteria of roles) and requesting access (which then triggers the access request approval flow which can be empty). In a similar way there is a difference between directly revoking access (which certification reviewers can do) and requesting revocation of access (which then triggers the access request revocation approval flow which can be empty). I strongly suggest to use the right terminology in documentation, announcements and functionality to emphasize the “request” bit of revoking access. For example: End users can not revoke their own access, they can REQUEST revocation of their own access, which then has a (potential empty) approval flow assigned to it.
2. There is a global feature to set whether requesting entitlements are allowed or not. Will there be a second global feature now that allows us to enable entitlement revocation requests? Such that clients who don’t allow requesting entitlements can configure that they also don’t allow requesting revocation of entitlements, whilst others can allow requesting revocation of entitlements even though they don’t allow requesting entitlements directly. (which can be useful for example as part of cleanup activities).
3. How will revoking access behave with respect to segmentation? Suppose we have segment X with role A and segment Y with role B. Suppose I am part of segment X and not of segment Y. I am able to request role A for (for myself, and also for someone else). I can not request role B for myself, nor for someone else.
   3.a I understand I will now be able to request revocation of role A for myself, but can I request revocation of role B for myself?
   3.b In addition suppose I have the new Access Revoker User level. I understand I will now be able to request revocation of role A for someone else, but can I also request revocation of role B for someone else?
4. How will revoking access behave with respect to end date? Can I request the revocation of a role, where I want revocation to occur at the end of the month? If so, will it properly trigger the access revocation approval flow?
5. How will revoking access behave when different requests are in-flight?
   5.1 Suppose I make an access request to prolong the end date of a role I currently have. While this access request is not approved yet by the approvers, suppose someone else performs an access revocation request for this role on my behalf. Will the request now fail? If it continues and it leads to deprovisioning, will it also kill my current access request? Or will that one, once approved trigger reprovisioning again?
   5.2 How does this work if certain access is managed indirectly which could take a long time (for example through a ServiceDesk integration or manual task, where it can take the responsible person a couple of weeks to finish the provisioning). Suppose I request a role pointing to several direct sources and one ServiceDesk based source. It gets approved and the direct sources get provisioned and a service ticket is created. Two weeks later the access request is still labeled with state EXECUTING.
   Suppose I will now request revocation of the role. What should happen? Note that ‘two weeks’ here is arbitrary, it could also be one day or 2 months.
6. Suppose I have an access profile with entitlements A and B, and I have mapped this access profile to a role and assigned this role to some identities, but not to identity X. Also suppose Identity X already has entitlement A, which they should have, but someone now added entitlement B directly on the target application. We aggregate the account and see identity X now has both A and B. We can not not use the access certification in Identity Security Cloud to deprovision entitlement B for this identity. This is because ISC thinks the identity has the access profile, and therefore ISC doesn’t allow us to revoke the entitlement. Instead we can only revoke the whole access profile through certification, meaning entitlement A will unfortunately be deprovisioned as well. Is this undesired effect also present in access request revocation? So can Identity X request revocation of an entitlement if identity X also has different entitlements as well that together happen to form a set of entitlements defined in some access profile, even when Identity X never requested this access profile or any role associated to it?
7. If an entitlement aggregation yields a new entitlement, there is always a bit of time between when we can update the specific access revocation approval flow on this entitlement flow. So it is definitely good that there is a global config and a source based config for this, such that can put a strong revocation approval flow by default and can decide later to put an entitlement revocation approval flow on the entitlement itself if we want to overwrite the strong revocation approval flow (principle of least privilege and security by principle). But how can we now distinguish entitlements where we haven’t overwritten the revocation approval flow, from entitlements where we have overwritten the revocation approval flow, where our decision was to have no approvers needed at all?
8. In the announcement you are mentioning action is required, where you are encourage us to set up entitlement revocation approval requirements. Here you are linking to an API that is currently in an experimental state. The SailPoint API versioning strategy distinguishes Public APIs from Experimental APIs, where public APIs are “production ready APIs that are meant to be used by customers, partners, and other external users” and where experimantal APIs are “still under development, but may be used by customers, partners, and other external users for evaluation purposes” and are offered to the public “in order to get feedback from users on how we can improve them before they are released into production”. Will this API be made public and thus marked as production ready before this new functionality is deployed to production such that the SailPoint API Versioning Strategy is being followed and we know we can safely use this API in production?
9. Will all documentation on this be released as soon as the functionality will be released to our sandbox environment, such that we can play around with the functionality with this documentation in mind and see when there is a mismatch between documentation, expected behavior and observed behavior?
10. If you release the option to request revocation of entitlements at the same moment you are releasing the option to configure the access revocation request approval flow, there will be no time for administrators to properly setup the configuration and the wrong configuration with no approval flow will then by default be visible, meaning end users can bypass the to be configuration flow. To prevent this security issue. Will this functionality be released in two parts? Where the first part allows administrators to configure the access revocation request approval flow in the proper way, without it being active yet, and the second part will activate this configuration? Or even better, will the release by default contain the global configuration of allowing entitlement revocation requests to be marked as not allowed, such that admins have the time they need to prepare the configuration prior to turning it on themselves?

Once again, I really look forward to this and I hope you can clarify these questions. I am sure others would be interested to know of (a least some of) these answers as well.

Kind regards,
Angelo

[jrossicare (Jason Ross)]

@jennifer_mitchell

Because access profiles can only be assigned once per identity

What does this mean, “Because access profiles can only be assigned once per identity”?

Thanks

[jennifer_mitchell]

Answering your questions @angelo_mekenkamp :

1. For simplicity of button labeling, we have called it “Revoke Assignment” (or Revoke [object name]), since that’s what the user is trying to do when they click it. But once they click that, the confirmation message tells them their revocation request has been submitted. And the request will follow any configured revocation approval requirements before access is removed. Documentation explains the approval step as well.
2. At this time, all entitlements and access profiles that are not controlled by a role are revocable. We will gauge customer need for further restrictions and will address that in the future as needed.
3. Revocation is not segmented. Users can revoke any revocable access held by the identities they are authorized to revoke for (self, team, everyone).
4. This question conflates two different concepts – revocation and expiration. Approvals happen at the time of request. If you request to revoke an existing end-dated assignment now, we will follow the revocation approval path now and override the fact that the assignment was previously scheduled for future auto-revocation. If you request access with an expiration date, approval will happen at request time, not at that future revocation date. At that future date, revocation will happen with no further approval.
5. The revoke and date-change requests you described are treated as separate requests with no interdependencies or cross-cancellation. A request to change an expiration date is processed as a Grant request, so if the revocation request is approved (and access is deprovisioned) before the date-change request is approved, the date-change request will be treated an add-access request with the specified expiration date. It is up to your approvers to approve requests for access users should have and deny requests for access they should not have, or to your requesters or requestees to cancel no-longer-relevant requests.
   If requests are provisioned through a ticketing system or manual task, any approved requests will create tickets/tasks in the order they reach the provisioning step, and it is up to the assignees of those tickets/tasks to manually apply or not apply the requested actions.
6. For the very reason you described, we will be allowing you to request revocation of any entitlement that rolls up to an access profile but not to a role assignment. You can still revoke the access profile to remove them all, but you can also individually revoke each entitlement. Note that this will be true even if you had requested the access profile, since we don’t currently track the distinction between requested and detected access profiles.
7. It is not currently supported to define a global approval requirement and then have no approval required at a per-entitlement level. You can change the approver requirement per entitlement but if you don’t set one per entitlement, the higher level (source or global) will be applied. That is not changing with this revocation enhancement.
8. The team that owns that source-level approval config API endpoint is working on promoting that to a public status. In the meantime, you don’t have to use it, but if you want to configure approval requirements per source, that’s how you do it.
9. Our documentation process is to release docs when the functionality goes to production for the first customers.
10. This feature will be released as a single unit. If you are concerned about erroneous self-revocation out of the gate, I recommend starting by setting revocation approval requirements at the global level right away, as a safeguard while you manage configuring the lower levels as needed. That said, the Access Revoker level has to be explicitly enabled, so the broader ability to revoke for others will not automatically be in place for anyone but org admins.

[jennifer_mitchell]

@jrossicare
An AP is associated to a user when we detect its required entitlements on the identity. This is the case even when the AP is requested. That detection process only detects the AP once per identity. Therefore, ISC will only associate an AP to an identity once. There is one exception - if a role is assigned more than once and the detection is done to determine that the role has been properly provisioned, the detection can be done under those role assignments more than once, but in that case, those APs aren’t revocable outside of the role (you have to revoke the role itself to revoke that access. So at most, there will only be a single instance of a revocable AP associated to an identity.

[angelo_mekenkamp]

Thank you for your quick response and clear answers @jennifer_mitchell, we will take these answers into consideration when planning our next steps.

Your answers do trigger the following follow-up questions.

Regarding point 2. I am not sure this answered my question, so let me rephrase. If we have Enable Entitlement Requests turned off in /ui/admin#admin:global:system:features, because we only want to assign access through a role model, then we can’t request entitlements. But with this turned off, can we still request the revocation of these entitlements? For example to get rid of entitlements that are currently not granted through a role? So will there be some kind of Enable Entitlement Revocation Requests option we can use to globally allow or disallow entitlement revocation requests?

Regarding point 4. revocation and expiration can be tied together. For example if I already have a role without end date, I can call the access request API, specify requestType=REVOKE_ACCESS and pass a removeDate for the end of the week. This will then trigger the access revocation approval flow right? (as expected, since I am losing future access). I wonder how I can achieve the same result through the UI.

Regarding 7. So if an organization wants a specific AD group to be requestable without approval flow, they can’t use the global approval flow anymore and therefore it will be the case that newly incoming AD groups (through aggregations) will be requestable for all identities without any approval flow, until we assign the proper approval flow.

Regarding 10. “If you are concerned about erroneous self-revocation out of the gate, I recommend starting by setting revocation approval requirements at the global level right away”. This makes sense. But exactly because this feature will be released as a single unit, we cannot prepare for this release by having the global level approval flow in place for entitlements. So we have to wait until it is possible to commit erroneous self-revocation on entitlements before we can enable the security controls against it. To follow the security by design principle, would it be reasonable that SailPoint either releases this functionality in two-fold, allowing us time to have the security controls in place prior to this release, or otherwise have this feature be released as a single unit, where SailPoint has already incorporated the principle of security by design. For example to have a prepopulated global revocation approval flow on entitlements, or even better, by releasing this with the Enable Entitlement Revocation Requests turned off, allowing org admins to put the desired security controls in place and once satisfied on the level of security, they can then enable this feature themselves.

Kind regards,
Angelo

[tysremi (Remi Tys)]

10. Following least privileged principle, isn’t it already more secure by allowing self-revocation requests out of the gate?
    Org admins already had the power, and the access to revoke for others needs to be granted. Managers could already revoke accesses for their direct reports.

In any case, looking forward to this release!
It will deprecate some launchers/workflows we had to create to simulate this feature. (Revoke for self/others)

[angelo_mekenkamp]

@tysremi: For roles and access profiles revocation requests by admin/manager was indeed already possible, but for those you can specifically set the revocation approval flow before you mark these roles or access profiles as enabled.

Entitlement revocation requests is new, even for managers and org admins, and also the access revocation request approval flow here is new. These empty approval flows will now followed by ISC before org admins get the chance of populated them.

I understand that is can sound a bit counterintuitive, but it is definitely not more secure by allowing self-revocation requests out of the gate. Here are some reasons why:

1. Getting rid of certain access yourself could trigger deletions of accounts, which could disrupt the business. it is not always easy for end users to understand what the impact would be of revoking their own access.
2. Suppose an incident occurred and an end user can now not investigate the incident because they accidentally revoked their own access. The incident will now take more time to resolve.
3. People on the internet were tricking others to delete their system32 folder on their own computers. Sometimes the way to protect end users would be to prevent them from removing things on their own (or at least make sure they really know what they are doing).
4. I understand it is an anti-pattern but suppose you have a blacklist of colleagues who misbehaved and are not allowed to perform a certain task and this blacklist is described as an AD group. Losing this AD group would mean you are not on this blacklist anymore. So sometimes losing an entitlement like this AD group could trigger more access being possible. Notice that this anti-pattern exists even when you don’t expect it.
5. I can bypass an SoD conflict now by revoking the previous access myself and then requesting the new access. No conflict is visible now, so it will not be detected as such. I was now able to first do part A, then lose this access, request new access for performing part B. An approval flow could allow an approver to first check if I did not prepare anything malicious prior to revoking the access, prior to me being able to request the second bit while avoiding the SoD conflicts.

All in all, a revocation approval flow is to ensure that losing particular access will not result in issues. And of course you don’t have to set the revocation approval flow if that makes more sense for your organization, but allowing tenants to implement the security before the functionality goes live is definitely more secure than releasing the functionality in an enabled state without having the security controls in place already.

Kind regards,
Angelo

[tysremi (Remi Tys)]

I was mostly jesting since no access is the safest access :-). The blacklist group is a scenario that didn’t come to mind directly..There are indeed some use-cases in that area that could lead to insecure access, most of the others just lead to inefficiency.

[benjaminoriold]

Hi Jennifer, glad to see this coming to production!

I’d like some clarification on #2 here: What you’re saying is still the case even if we have Entitlement Requests turned off at the global level, correct? Our org would want this new feature for Entitlement Revoke Requests enabled but Entitlement Grant Requests not possible at the same time, which I think is the use case Angelo was getting at.

For #9 I have to say I’m disappointed that this is the documentation process SailPoint has decided to go with. Why not release to documentation to us while the feature is available in our Sandbox environment? This would allow us more ability to test what is possible and prepare for the actual production release, rather than scrambling to put things together as soon as the feature goes live. Considering it’s about a week between the two, I don’t see what the problem or potential downfall is to giving us access to the documentation now.

[benjaminoriold]

Also can we get confirmation on an exact day this will be in production? I’m assuming it is May 5th itself, but want to be sure if possible since it just says the “week of May 5th” for rollout.

[angelo_mekenkamp]

This functionality is now available in our sandbox environment. I played around with it and noticed the following things:

1. If you request an access profile with entitlements and get it approved/provisioned, and then go to MyAccess → Entitlements and then click on one of those entitlements, you will not see the access profile as assignments. This is different to the manager, who is able to see the access profile as assignment when they click on the entitlement of their direct report. Why is this different?

2. If you want to revoke an entitlement for yourself, when you go to My Access → Entitlements, there is currently no functionality to search for the entitlement (needle in a haystack). You have to paginate over the list (which can have hundreds or thousands of entitlements) until you find it. No filter options, no way to sort by name or source (not sure what the current sorting is). This is of course not a show stopper as it is still a functionality improvement, but I can imagine end users asking for this soon.

3. If you have the global setting “Enable Entitlement Requests” turned off, meaning you don’t want users to request single entitlements, then end users will also not be able to request revocation of their own entitlements. Note that the UI suggests it is possible as the button is visible, but if you continue and try to revoke it, you will get this error:
   

   

4. I created an access profile with Entitlement A and Entitlement B and then requested this access profile for myself with removeDate last day of this month. It got approved and provisioned and I fetched and stored the search JSON of the identity. Then I requested revocation of Entitlement A through the UI. Once approved, I again took the search JSON and compared the two. See screenshots for the differences:

Note that now in search, it is clear that I last Entitlement A, but also you can see that Entitlement B has become a standalone entitlement, and that according to search I don’t have this access profile anymore. I now don’t see anything in search anymore, that would suggest that Entitlement B will be removed from my account on the end of May. If it will not get removed because the access profile with removal date is no longer there, I am able to prolong entitlements by revoking another. If it will get removed, we would be surprised because this is not visible in search anymore as the access profile with removal date is not shown on the user. So it seems that regardless of the behavior on the end of the month, it will have a negative effect. Has this scenario been taken into account, and is this the expected behavior?

Kind regards,
Angelo

[jennifer_mitchell]

Answering one question that a couple of you have asked a couple of different ways: If entitlements are globally not enabled for access requests, we will also not be letting you revoke entitlements with this enhancement. As long as you globally enable requests, even if no entitlements are individually requestable, you will be able to revoke them.

[jennifer_mitchell]

A couple of notes on your latest reply @angelo_mekenkamp -

• We did not intentionally change the details displayed on that My Access page. If there are discrepancies that are not due to permissions differences, we can look into enhancements to make them parallel.
• Yes, we know that more search/filter options on My Access would be helpful and we are working to determine when that work can be done in the future.
• I will revisit the visibility of the revoke button when entitlement requests are globally turned off with my team.
• As I recall, I did test a scenario like the one you describe with removing part of an end-dated access profile, but before I assert that it definitively will work one way or the other, I need to look into that again.

[angelo_mekenkamp]

We are now looking into this option, as this could be indeed the way you can disallow requesting entitlements, while still allowing the revocation of it.

(This is an edited message, I first raised a concern on new entitlements being marked requestable by default, but this is actually not true (anymore?))

[angelo_mekenkamp]

Visible on My Access when clicking an entitlement:

Visible on My Team when clicking on the same entitlement of the same direct report as the one above:

I now see that besides the access profile message that the entitlement type is also missing at the top.
Besides here, also in the My Access page and My Team page, entitlement type is missing. This makes the list ambiguous, for we know of several examples where we have a source with multiple entitlement types, where we have two entitlements that have both the same entitlement name and entitlement value (external id of the entitlement), but only have different entitlement types. For these ones, the identity who wants to get rid of one of the two now doesn’t know which one to select.