WIP: Group assignment from JWT claims #2568
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a natural follow-on from #2388 and was initially floated in discussions #2205 and #2206. This PR is a WIP with some pretty obviously missing pieces, specifically error handling,
.env.sample
examples, and tests, which I will gladly add but wanted to be sure that how I'm going about this is acceptable before adding the polish.Additions
accountProvisioner
. If no claim is present then there is no effect.roles
instead ofgroups
or anything similar.accountProvisioner
will pass the groups to a newgroupCreator
file in/commands
.groupCreator
first ensures that the group exists, and if not will create it.groupCreator
will then ensure that the user is a part of the group, and if not will add them.accountProvisioner
will then remove any GroupUser records that are not present in the current list of groups passed to it; currently this includes groups that were assigned manually, however if no groups are passed to theaccountProvisioner
then it will not remove any group assignments, and therefore should not interfere with existing setups. It will also not delete any group, even if there are no members.Configuration
OIDC_GROUPS_CLAIM
— The name of the claim provided that contains the list of groups a user belongs to. Currently defaults togroups
although we may wish to have it default to a disabled state to guarantee that existing deployments will not be affected by stray configuration.Further configuration will be necessary from the IdP side; as this likely requires additional scopes that will add the required claim referenced in the env variable above. For example, on Keycloak this would require creating a "mapper" that has that effect.