Option to use Username instead of email when logging in via oidc #365

@JulienFloris commented on GitHub (Mar 22, 2023):

Same issue here.
i have userName@example.com and limited the sign in options to only allow users from "example.com". Only some users have a mismatch in email serviceDesk@FrondEndwebsite.com. And then these users are blocked. usually the UserPrincipalName is used not the email associated to it.

i do really love the OpenID Connect Option and the Doc's, but a option or fix for this would make it even beter.

@JulienFloris commented on GitHub (Mar 22, 2023): Same issue here. i have userName@example.com and limited the sign in options to only allow users from "example.com". Only some users have a mismatch in email serviceDesk@FrondEndwebsite.com. And then these users are blocked. usually the UserPrincipalName is used not the email associated to it. i do really love the OpenID Connect Option and the Doc's, but a option or fix for this would make it even beter.

adam commented

@github-actions[bot] commented on GitHub (Sep 28, 2023):

This issue is stale because it has been open for 180 days with no activity.

@github-actions[bot] commented on GitHub (Sep 28, 2023): This issue is stale because it has been open for 180 days with no activity.

adam commented

@joachimtingvold commented on GitHub (Oct 2, 2023):

This is very much still relevant, especially after the PR was closed due to "re-organizing" (#1287 + #1473).

@joachimtingvold commented on GitHub (Oct 2, 2023): This is very much still relevant, especially after the PR was closed due to "re-organizing" (#1287 + #1473).

adam commented

@almereyda commented on GitHub (Oct 3, 2023):

Is this about supporting claims?

https://openid.net/specs/openid-connect-core-1_0.html#Claims

@almereyda commented on GitHub (Oct 3, 2023): Is this about supporting claims? - https://openid.net/specs/openid-connect-core-1_0.html#Claims

adam commented

@meson800 commented on GitHub (Oct 29, 2023):

I'm working on an update for #1287 now, looking at how the code has been reorged.

@meson800 commented on GitHub (Oct 29, 2023): I'm working on an update for #1287 now, looking at how the code has been reorged.

adam commented

@meson800 commented on GitHub (Nov 15, 2023):

@kradalby, do you want me to open a new PR or reopen the earlier one? A fix for this is freshly rebased after the code reorganization and is reasonably ready to go in #1287.

@meson800 commented on GitHub (Nov 15, 2023): @kradalby, do you want me to open a new PR or reopen the earlier one? A fix for this is freshly rebased after the code reorganization and is reasonably ready to go in #1287.

adam commented

@FStelzer commented on GitHub (Dec 5, 2023):

Thanks for working on this. I think this needs to be a bit more flexible than just choosing between preferred_username & email.
See: https://learn.microsoft.com/en-us/entra/identity-platform/migrate-off-email-claim-authorization
There should probably be some unique user identifier claim (like MS suggests using TID+OID) and additional info about the user (email/username) to make them easier to identify

@FStelzer commented on GitHub (Dec 5, 2023): Thanks for working on this. I think this needs to be a bit more flexible than just choosing between preferred_username & email. See: https://learn.microsoft.com/en-us/entra/identity-platform/migrate-off-email-claim-authorization There should probably be some unique user identifier claim (like MS suggests using TID+OID) and additional info about the user (email/username) to make them easier to identify

adam commented

@meson800 commented on GitHub (Jan 10, 2024):

I'll poke around the current auth code, but I think right now there isn't an assumption of a unique user identifier claim in Headscale. Perhaps there's a nice way to link this. The username is nice because you could migrate between OIDC providers technically without recreating users.

I don't know what the best way to handle username updates would be though, as node MagicDNS names are tied to username.

@meson800 commented on GitHub (Jan 10, 2024): I'll poke around the current auth code, but I think right now there isn't an assumption of a unique user identifier claim in Headscale. Perhaps there's a nice way to link this. The username is nice because you could migrate between OIDC providers technically without recreating users. I don't know what the best way to handle username updates would be though, as node MagicDNS names are tied to username.

adam commented

@FStelzer commented on GitHub (Jan 15, 2024):

username/email/identifier changes in headscale (including magic dns, acl's) will probably always require manual interaction to fix.
Problematic is the case when headscale uses something like the email as unique identifier when in the OIDC provider it is not. So if the OIDC Provider allows the user to edit their email or username field (maybe not even unique) I could potentially assume another persons identity by setting my email field to theirs.

I know that this is only partly headscales responsibility since it needs a unique identifier that is also humanly readable for things like acls. Making this unique field at least freely configurable allows me to fix this within the OIDC mapping whereas the email for example is often not allowed for remap.

@FStelzer commented on GitHub (Jan 15, 2024): username/email/identifier changes in headscale (including magic dns, acl's) will probably always require manual interaction to fix. Problematic is the case when headscale uses something like the email as unique identifier when in the OIDC provider it is not. So if the OIDC Provider allows the user to edit their email or username field (maybe not even unique) I could potentially assume another persons identity by setting my email field to theirs. I know that this is only partly headscales responsibility since it needs a unique identifier that is also humanly readable for things like acls. Making this unique field at least freely configurable allows me to fix this within the OIDC mapping whereas the email for example is often not allowed for remap.

adam commented

@meson800 commented on GitHub (Feb 19, 2024):

I'm considering implementing something similar to Matrix Authentication Service's user attribute mapping, which would make it generalizable:
https://matrix-org.github.io/matrix-authentication-service/setup/sso.html#user-attributes-mapping

@meson800 commented on GitHub (Feb 19, 2024): I'm considering implementing something similar to Matrix Authentication Service's user attribute mapping, which would make it generalizable: https://matrix-org.github.io/matrix-authentication-service/setup/sso.html#user-attributes-mapping

adam commented

@xaemiphor commented on GitHub (May 10, 2024):

I'm not sure where is the best place to document an explicit use case, I'm still surprised #1287 is simply closed.

I've just setup headscale backed by LLDAP + Authelia. I'm not pairing any email solutions that would require my users maintain restricted username@domain.com in the email field of their profile, like we would see if I deployed headscale using Google OIDC. Other applications I'm using with Authelia appear to be importing both the preferred_username and email fields, the email is specifically loaded by applications that expect to be able to send outbound emails.

So with this setup, someone could simply update their email in the LLDAP dashboard to match another user's email username in order to enroll nodes under their user account. IE user-a/coolkid1992@hotmail.com and user-b/coolkid1992@aol.com would both be interacting with headscale as coolkid1992.

From my rough understanding of the OIDC, headscale is generally set to request openid profile email and optionally groups scopes. profile offers a preferred_username field, I recognize that might not be unique either according to different OIDC providers, but I believe the openid scope subject is supposed to be a user-unique uuid to represent the user that logged in(I'm not sure offhand how authelia comes up with this mapping, but will assume they're following OIDC expectations)? Wouldn't a sensible mapping be to store this UUID to the user table for 1:1 user mapping regardless of username/email, update the username/email on login, and make sure all internal DB relationships are using using either this UUID or the ID column of the table?

@xaemiphor commented on GitHub (May 10, 2024): I'm not sure where is the best place to document an explicit use case, I'm still surprised #1287 is simply closed. I've just setup headscale backed by LLDAP + Authelia. I'm not pairing any email solutions that would require my users maintain restricted `username@domain.com` in the `email` field of their profile, like we would see if I deployed headscale using Google OIDC. Other applications I'm using with Authelia appear to be importing both the `preferred_username` and `email` fields, the `email` is specifically loaded by applications that expect to be able to send outbound emails. So with this setup, someone could simply update their email in the LLDAP dashboard to match another user's email username in order to enroll nodes under their user account. IE `user-a/coolkid1992@hotmail.com` and `user-b/coolkid1992@aol.com` would both be interacting with headscale as `coolkid1992`. From my rough understanding of the OIDC, headscale is generally set to request `openid` `profile` `email` and optionally `groups` scopes. `profile` offers a `preferred_username` field, I recognize that might not be unique either according to different OIDC providers, but I believe the `openid` scope `sub`ject is supposed to be a user-unique uuid to represent the user that logged in(I'm not sure offhand how authelia comes up with this mapping, but will assume they're following OIDC expectations)? Wouldn't a sensible mapping be to store this UUID to the user table for 1:1 user mapping regardless of username/email, update the username/email on login, and make sure all internal DB relationships are using using either this UUID or the ID column of the table?

adam commented