Option to use Username instead of email when logging in via oidc #938
Comments
|
Same issue here. i do really love the OpenID Connect Option and the Doc's, but a option or fix for this would make it even beter. |
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs.
|
This issue is stale because it has been open for 180 days with no activity. |
|
Is this about supporting claims? |
|
I'm working on an update for #1287 now, looking at how the code has been reorged. |
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
|
Thanks for working on this. I think this needs to be a bit more flexible than just choosing between preferred_username & email. |
|
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. |
|
username/email/identifier changes in headscale (including magic dns, acl's) will probably always require manual interaction to fix. 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. |
|
I'm considering implementing something similar to Matrix Authentication Service's user attribute mapping, which would make it generalizable: |
Previously, Headscale would only use the `email` OIDC claim to set the Headscale user. In certain cases (self-hosted SSO), it may be useful to instead use the `preferred_username` to set the Headscale username. This also closes juanfont#938. This adds a config setting to use this claim instead. The OIDC docs have been updated to include this entry as well. In addition, this adds an Authelia OIDC example to the docs. Added OIDC claim integration tests. Updated the MockOIDC wrapper to take an environment variable that lets you set the username/email claims to return. Added two integration tests, TestOIDCEmailGrant and TestOIDCUsernameGrant, which check the username by checking the FQDN of clients. Updated the HTML template shown after OIDC login to show whatever username is used, based on the Headscale settings.
|
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 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 From my rough understanding of the OIDC, headscale is generally set to request |
|
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 <#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
<#938 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOEWD2IKB5D7CRIDDVIMCTZBUO2HAVCNFSM6AAAAAARZQKSNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGE3DSOBSGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@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 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... |
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.
The text was updated successfully, but these errors were encountered: