-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gracefully report duplicate usernames #3481
Merged
dbutenhof
merged 2 commits into
distributed-system-analysis:main
from
dbutenhof:dupuser
Jul 10, 2023
Merged
Gracefully report duplicate usernames #3481
dbutenhof
merged 2 commits into
distributed-system-analysis:main
from
dbutenhof:dupuser
Jul 10, 2023
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
ndokos
previously approved these changes
Jul 6, 2023
webbnh
previously approved these changes
Jul 7, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, assuming the answer to my question is no big deal....
PBENCH-1198 With the move from a private Keycloak ID provider to Red Hat SSO, we find that several user UUID values (from the old and new ID provider) are attempting to claim the same username. The current user "cache" doesn't allow for this, nor in general does it seem we really want to be casually mapping multiple "users" across ID providers into the same "Pbench identity" just because they share a username. Instead, diagnose this problem with an authorization failure and an explicit error message instead of letting the Auth module hide the error and silently treat the client connection as unauthenticated. Note that we can manually fix this by manually renaming the old user entry in SQL, which will allow the server to recognize the new SSO login. We can then reassign any existing datasets from the old user to the new user.
webbnh
approved these changes
Jul 10, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
ndokos
approved these changes
Jul 10, 2023
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.
PBENCH-1198
With the move from a private Keycloak ID provider to Red Hat SSO, we find that several user UUID values (from the old and new ID provider) are attempting to claim the same username. The current user "cache" doesn't allow for this, nor in general does it seem we really want to be casually mapping multiple "users" across ID providers into the same "Pbench identity" just because they share a username.
Instead, diagnose this problem with an authorization failure and an explicit error message instead of letting the Auth module hide the error and silently treat the client connection as unauthenticated.
Note that we can manually fix this by renaming the old user entry in SQL, which will allow the server to recognize the new SSO login. We can then reassign any existing datasets from the old user to the new user.