Does anybody have any GOOD ways to either allow users to self-revoke entitlements or make entitlements NOT ‘sticky’ to a source?
As many others have posted before me, the simple fact is sometimes application owners need to change data/permissions on the target application for whatever reason. Or, a user is done with a certain function and no longer needs access to dataset or entitlement, but needs a new one to replace it. This doesn’t necessarily mean a team or manager change in the authoratative source. Entitlements via Access Requests are ‘sticky’ - so if the owner removes the role/entitlement on the target side, Sailpoint will add it back on next aggregation. So - how do we get around this? The list of options or discussions I’ve seen across various posts are below. In my opinion none of them are good (or don’t exist). So does anyone have any GOOD methods to get around this? What is YOUR company doing about it?
-
Self-Service: Self-Revocation would at least help, but as we know there is no self-service revocation feature (which is insane). At least we could rely on best-effort from the user and catch outliers with a campaign periodically. There’s been an idea open for years with hundreds of votes but no action.
-
Forms: Well, I suppose we could fill the feature gap of no self-service with forms, IF you could put a form right on the dashboard for end-users. The idea of trigging an external source to kick off a workflow to THEN assign a form to an end user (and then another workflow to act on that form) is ridiculous. That’s not a ‘good’ solution at all. I would also like to say if we can handle self-service revocation via a form there is no excuse for this not to be built-in to Sailpoint. None at all.
-
ISC Admin Revoke via Entitlements page: Not a good solution, end users don’t know who to reach out to for this, nor should they. In most cases they would reach out to the target app owner (who then has to reach out to an ISC admin). This is wasteful and too manual of a process.
-
Access Profiles vs. Entitlements: I understand that Access Profiles are not ‘sticky’, so one option is replace all the Entitlements with a one-to-one relationship with a new Access Profile and stick them in there. Again - this is a possibility but not ‘good’ as it would require us to re-structure our entitlement/access request design over again. Additionally I think managers can remove access from their employees IF they are Access Profiles (not entitlements) right?
-
Connector Setting: I haven’t heard of such a thing but why the devil could this not be a per-connector setting, to enable ‘sticky’ entitlements or not? Just have some setting that doesn’t write entitlements back to the source on aggregation operations (only for create-account and add-entitlement).
-
Source Sub-Admins: Well I got excited for a second because it looked like if I gave the app owner the Source Sub-admin user level AND made the source itself managed by a governance group, that they would be able to search through Entitlements → View Identities → Revoke that way (like an ISC admin would). But…when he tried, nothing happened. It gave him the ‘success’ message like his revocation processed, but there are no events or activity in log, nothing. Also it appeared he could revoke entitlements for any other source too (well, if it worked, that is). Is that by design?
-
Delegation: I’m aware of some 2025-ish idea to delegate admin levels more granularly - maybe that would be an option similar to my above attempt at Source Sub-Admins - but that’s 2025 (and who knows what quarter).
Any other possibilities I am missing here?