Customers want it to be easy to revoke access from a user who no longer needs it, to promote and facilitate least-privilege access across their organizations.
We are continuing to validate our understanding of the problem space and solution. In addition, we are conducting research calls focused on validating our designed solution, better understanding the desired user experience, and ensuring we hit the most common customer use cases.
Our Product Management team would love to hear from you! Here’s how:
Voice your thoughts, questions, comments, and concerns right here in this topic.
Vote on the idea linked above.
or schedule a call to discuss this topic further, and provide insights specific to your business problem and use cases. If you don’t see a calendar opening that aligns with your availability, feel free to send me a direct email.
I have a question related to this: Will this feature automatically remove access from sources when users no longer have any entitlements?
For example, if a user doesn’t have an account on a source, but becomes eligible for an entitlement (either by birthright or request), the system creates the source account and adds the entitlement. However, when the user no longer needs access, only the entitlement is revoked, leaving the account active. Can this feature disable such accounts?
Sorry about that - the formal discovery effort on this item ended a while ago, but as the revocation work hasn’t yet been scheduled, I’ve updated the article to point to my generic 30-minute Calendly meeting URL. I’d love to hear your input on this if you want to schedule a meeting with me!
For Managers, currently it displays all the existing access for the reportees just like Access Reviews. Along with that, managers can select Identity and search for access to revoke out of all the access reportee has.
Currently we can revoke Role for an Identity from Roles page. Same feature for Access Profiles and Entitlements.
These features may not be released at once, SailPoint will give the priority.
Thank you @jennifer_mitchell. It was indeed a progressive discussion on the feature for requesting access revocation in view of different roles in SailPoint.
Adding to the topics Krishna has shared, below are few more points that are discussed as part or our meeting.
Requesting existing access
Earlier versions of ISC didn’t allow users to request the access which already was assigned. However, since almost 11 months, the new UI allows users to place a request for the already assigned access, only to get it failed with a notification to the user that it was an existing access. Jennifer explained the challenge behind this, as the old UI only allowed requesting access for user at once, the new one allows for multiple users at once for the same access profile. Indeed a valid reason, hope we have another solution for this in future.
Expiration Date
Discussed probable features which would be useful for various use cases
To be able to set a threshold for expiration date and optional configuration on access profiles or requestable objects to have it mandatory similar to comments
To show the expiration date currently set for an existing access while making a request
To modify(extend/decrease) the expiration period of the existing access from request center. It is still possible currently as well, users are allowed to place a new request with new expiration date for existing access which takes the precedence over the existing expiration date.
SailPoint also mentioned about exploration of requesting access on a sunrise date . All these requested features are in backlogs or ideas portal which SailPoint is looking into and planning accordingly.