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

[Polsaker]

From testing on headscale 0.17, the email field is used when logging in via oidc.

In some providers like headscale, the email is not immutable (it can be changed by the user at any time) but the username is not. It would be nice to have a way to make headscale use that field instead of email.

[JulienFloris]

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.

[github-actions[bot]]

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

[joachimtingvold]

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

[almereyda]

Is this about supporting claims?

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

[meson800]

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

[meson800]

@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.

[FStelzer]

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

[meson800]

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.

[FStelzer]

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.

[meson800]

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

[xaemiphor]

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?

[meson800]

Looks like the combo of subject and issuer claims are unique: https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability

Maybe I'll update the PR to use this combo internally. That would be a pretty annoying UX though as a device suffix, so allow it to be linked to the preferred_username or email claim (as long as someone hasn't already linked to that "username")

It would need some CLI that would allow for changing that mapping, in case e.g. the upstream OIDC provider changes.

On Fri, May 10, 2024, 3:38 PM xaemiphor @.***> wrote:

I'm not sure where is the best place to document an explicit use case, I'm still surprised #1287 https://github.com/juanfont/headscale/pull/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 @.*** 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 @. and user-b/ @. 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?

— Reply to this email directly, view it on GitHub https://github.com/juanfont/headscale/issues/938#issuecomment-2105169825, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOEWD2IKB5D7CRIDDVIMCTZBUO2HAVCNFSM6AAAAAARZQKSNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGE3DSOBSGU . You are receiving this because you commented.Message ID: @.***>

[xaemiphor]

@meson800 thanks for the reply, feeling less crazy as I skipped the "official" tailscale experience, poking around tickets and am trying to migrate to tailscale from static wireguard configs. Half of my understanding at this point has come from poking around the headscale postgres db and comparing to headscale cli output. Just surprised that the username subject seemed to end up stale.

I definitely agree that displaying the Issuer+Subject to the user would be bad UX, but at least using it internally removes the risk of user impersonation and probably ease support for changing the source-of-displayname.

Looking over the contents of tailscale status --json from one of my clients, I notice that the nodes all list their userid, and then there's a table of users which map it back out with LoginName and DisplayName. So I don't think the tailscale client actually cares about username collisions as long as the ID is different... Though this train of thought would definitely break the logic behind the node DNSName.

I'm probably just making commentary that doesn't benefit enough of the userbase... so I'll quiet down since I don't have the cycles personally to offer any code for these comments...