Skip to content
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

Authproxy should have a separate header for username and preferred_username #3876

Open
2 tasks done
kotx opened this issue Dec 8, 2024 · 2 comments
Open
2 tasks done

Comments

@kotx
Copy link

kotx commented Dec 8, 2024

Preflight Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

According to https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims, user name is "End-User's full name in displayable form" (display name), and preferred_username is "Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace."

Even though preferred username can have special characters, some implementations don't handle this very well, and they have semantically different meanings (username vs display name).

Proposed Solution

The authproxy connector should have separate headers for specifying these values, such as a X-Remote-User-Name header in addition to the existing X-Remote-User.

Alternatives Considered

No response

Additional Information

No response

@nabokihms
Copy link
Member

I'm fine with adding a preferred user name header. @kotx would you like to go ahead and make the change?

@kotx
Copy link
Author

kotx commented Dec 12, 2024

Sure, glad to do that! Will be busy in the next week though, so if anybody else wants to grab it I wouldn't mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants