OIDC login #73
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "oidc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #38
cc @benaryorg @raito
Based on https://github.com/NixOS/hydra/pull/1298
Additional features:
Todo
ccd50ec7c5to19e57225baDraft: OIDC loginto OIDC loginA couple of typos, some practical concerns that I'm uncertain about.
Sorry for taking so long!
@ -261,6 +261,72 @@ default role mapping:Note that configuring both the LDAP parameters in the hydra.conf and viathe environment variable is a fatal error.OIDC Authentijcation backendTypo: Authentication
@ -264,0 +270,4 @@```<oidc>enable = 0 # 1 to enab letypo: enable
@ -155,1 +159,4 @@my $oidcCfgCache;sub downloadSettings {I think I preferred the previous name
downloadOIDCSettings, there isn't really that much context that makes it obvious that this is about OIDC without reading the implementation or call site?@ -166,0 +230,4 @@doEmailLogin($self, $c, "oidc", $claims->{email}, $claims->{name} // undef);if ($oidcConfig->{groups_to_roles}) {$c->user->userroles->delete;This could lock an admin out if they've been using stateful role membership up to now? Seems potentially annoying. I think this should probably be mentioned in the docs at the very least.
I mean there are several relatively simple ways to recover:
hydra-create-userEspecially considering that this needs a flag to be enabled to work at all.
@ -166,0 +237,4 @@my @mapping = @{$oidcConfig->{groups_to_roles}->{$group}};for my $mapped_role (@mapping) {next unless $mapped_role;$c->user->userroles->create({ role => $mapped_role });I'm not confident enough in my knowledge of the system as a whole to be sure of any of what I'm saying here, but...
This empties and recreates the users' roles in the DB on every login? Probably not an issue realistically, but it does cause some churn.
"Caching" the roles like this could also cause confusion when looking at users in the admin UI:
Maybe the roles should be stored in the session instead, and the admin UI should make sure to show that the roles are unknown due to coming from OIDC mapping?
Wouldn't it be way easier to just turn off that part of the UI when the user type is OIDC rather than having two places where roles can be stored?
Sure, that would be fine by me too.
@ -166,0 +196,4 @@accepted_alg => [$alg],verify_sub => sub { return 1; },verify_aud => sub { return 1; },verify_iat => sub { return 1; }We should probably validate the issued-at time in some way?
This is already happening in decode_jwt: https://metacpan.org/dist/Crypt-JWT/source/lib/Crypt/JWT.pm#L239
I wonder if we should prohibit stuff that's too far in the past though?
@ -166,0 +204,4 @@}unless ($decoded_token->{aud} eq $oidcConfig->{client_id}) {error($c, "Token audience/subject don't match ID token", 401);Shouldn't this be in verify_aud function passed to decode_jwt above?
19e57225bato6085ed2bad6085ed2badto3ca2e2fd7a3ca2e2fd7ato2b4d04e1732b4d04e173tocccec0822aView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.