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

OIDC First Logon - Force username / email address #16674

Open
2 of 6 tasks
tacerus opened this issue Aug 12, 2021 · 2 comments
Open
2 of 6 tasks

OIDC First Logon - Force username / email address #16674

tacerus opened this issue Aug 12, 2021 · 2 comments
Labels
topic/authentication type/enhancement An improvement of existing functionality

Comments

@tacerus
Copy link

tacerus commented Aug 12, 2021

  • Gitea version (or commit ref): 1.14.3, binary release
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No (--> there is no OpenID logon button)

Description

Hi,

Thanks for the great software!

I integrated Gitea with Keycloak via OpenID - it works smoothly! There is one small flaw I am noticing however: whilst the user is prohibited from changing their email address in their profile after signing up (which is perfect, as their should be no email-address inconsistencies across services hooked up to the SSO), they ARE given the option to set their email address at their first logon to Gitea.

It'd be fantastic if this could be prohibited / "greyed out" by an administrative option, in order for the user not getting tempted to modify the email address that is set in their SSO backend.
This would benefit environments which rely on consistent user profile data across services.

Screenshots

image

Best
Georg

Edit: I just realized that the same is the case with the username, which the user is being told "Non-local users are not allowed to change their username. Please contact your site administrator for more details. " in the profile (which is perfect), whilst they were able to define their own Gitea username upon their first OIDC authentication to Gitea. Maybe the hole "Register new account" section could be administratively set to force username and email address values, with the "Link to an existing account" section only allowing to link to an account matching the email address?
Apologies for the long description - I hope it makes sense.

@tacerus tacerus changed the title OIDC First Logon - Force email address OIDC First Logon - Force username / email address Aug 12, 2021
@noerw noerw added topic/authentication type/enhancement An improvement of existing functionality labels Aug 23, 2021
@jenklu-copia
Copy link

I realize this is pretty old, but have you tried the ENABLE_AUTO_REGISTRATION = true flag combined with the ACCOUNT_LINKING = auto flag? I think that might give you your desired behavior. It will skip the screen that allows users to set their username/email when logging in for the first time via OIDC. If no user with the IdP-provided email exists, it will create a new user, whereas if a user with the IdP-provided email already exists, it will link that login to the existing user. Users won't have a chance to set those parameters.

@mgx0
Copy link

mgx0 commented Oct 20, 2023

I realize this is pretty old, but have you tried the ENABLE_AUTO_REGISTRATION = true flag combined with the ACCOUNT_LINKING = auto flag? I think that might give you your desired behavior. It will skip the screen that allows users to set their username/email when logging in for the first time via OIDC. If no user with the IdP-provided email exists, it will create a new user, whereas if a user with the IdP-provided email already exists, it will link that login to the existing user. Users won't have a chance to set those parameters.

this is a workaround indeed. but the fact ENABLE_AUTO_REGISTRATION is required in order for ACCOUNT_LINKING to be working should be considered a bug. is there any issue about this please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/authentication type/enhancement An improvement of existing functionality
Projects
None yet
Development

No branches or pull requests

4 participants