Do not rely on claims to figure out user access + prepare for claims removal #16552
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 task
bergmania
approved these changes
Jun 19, 2024
bergmania
deleted the
v14/feature/do-not-use-start-node-and-allowed-apps-claims
branch
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prerequisites
Description
We're currently challenged by our claims and how they're tied to the tokens. Specifically, whenever we change something on a user or a user group, we need to revoke all issued tokens. But we won't revoke admin tokens, because we don't want to risk logging the current admin out.
This PR addresses these challenges by obsoleting the claims for user start nodes and "allowed apps" (sections). These are now resolved directly from the user instance, not from the token bound claims.
Eventually these claims will be removed. There will be a separate announcement for this, as it is potentially quite breaking for some.
What about the role claims?
We could in principle also remove the role claims (
ClaimsIdentity.DefaultRoleClaimType). At this point I'm a little weary about doing that, though.In effect this means an access token will carry over roles for the duration of its lifetime, even if a user is removed from one role and added to another.
Testing this PR
The backoffice should function as per usual - auth and endpoint protection based on "allowed apps" (sections) should still work.
Changes in user start nodes or "allowed apps" should be immediately visible for all users.