-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
oidc: default team #535
oidc: default team #535
Conversation
@nscuro Any thoughts on this? |
for (final String teamName : teamNames) { | ||
Team team = getTeam(teamName); | ||
if (team == null) { | ||
LOGGER.debug("Unknown team " + teamName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be logged as warn
, and with a bit more context IMO. Users should be able to see when their configuration can't be applied as expected.
Something like:
Cannot add user foo to team bar, because no team with that name exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
} else { | ||
// Only apply default teams during auto-provisioning, not on later updates: | ||
return qm.addUserToTeams(user, config.getPropertyAsList(Config.AlpineKey.OIDC_TEAMS_DEFAULT)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing it like this means that the default teams will be wiped upon next login, assuming team synchronization is enabled. So if the user logs out and in again, or simply switches to another browser / device, they will be back to no teams again.
There likely needs to be some additional logic in synchronizeTeamMembership
that accounts for default teams.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When team synchronization is enabled, the default teams are not taken into account at all.
The idea was that if you want team synchronization, you should manage your teams in your identity infrastructure. Only when you don't have team synchronization, you can use the default teams to give users initial/default authorizations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thanks for clarifying. I think I misunderstood what was being requested in #411 - I assumed it was about having a "catch-all" group for users who don't have any groups assigned yet in the IdP. Seems I missed the
For organisations that are happy to manage users within an application
part of the original issue description. Makes sense to me then.
1338a05
to
1c8554b
Compare
The assignment of (a) default team(s) happens once during user provisioning, to give administrators a chance to change the teams for a user later. The assignment of (a) default team(s) does not go through the indirection of an OIDC Group, and expects the administrator to directly specify the teams the user should be a member of. This is intentional, because otherwise it could be confusing what would happen when the mapping between OIDC Groups and Teams changes after a user was already provisioned. This also matches the UI, which primarily shows (and allows changes to) the 'Team membership' of a user on the 'OpenID Connect Users' page, rather than the OIDC Group membership. Fixes stevespringett#411
1c8554b
to
18ade6e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @raboof!
@stevespringett, this is good to merge.
Introduces: * Ability to assign default groups to OIDC users (stevespringett/Alpine#535) * Tracking of `created` and `lastUsed` timestamps for API keys (stevespringett/Alpine#537) * Addition of `comment` field to API keys (stevespringett/Alpine#537) Closes DependencyTrack#1068 Fixes DependencyTrack#1556 Closes DependencyTrack#3349 Signed-off-by: nscuro <[email protected]>
Introduces: * Ability to assign default groups to OIDC users (stevespringett/Alpine#535) * Tracking of `created` and `lastUsed` timestamps for API keys (stevespringett/Alpine#537) * Addition of `comment` field to API keys (stevespringett/Alpine#537) Closes DependencyTrack#1068 Fixes DependencyTrack#1556 Closes DependencyTrack#3349 Signed-off-by: nscuro <[email protected]> Signed-off-by: Mikael Carneholm <[email protected]>
The assignment of (a) default team(s) happens once during user provisioning, to give administrators a chance to change the teams for a user later.
The assignment of (a) default team(s) does not go through the indirection of an OIDC Group, and expects the administrator to directly specify the teams the user should be a member of by default. This is intentional, because otherwise it could be confusing what would happen when the mapping between OIDC Groups and Teams changes after a user was already provisioned. This also matches the UI, which primarily shows (and allows changes to) the 'Team membership' of a user on the 'OpenID Connect Users' page, rather than showing the OIDC Group membership.
Implements #411