Skip to content
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

Adding roles as a claim, that are dependent to groups of the user identity provider as configurable layer between groups and the roles claim #2215

Open
2 tasks done
nolem opened this issue Jul 26, 2021 · 2 comments

Comments

@nolem
Copy link

nolem commented Jul 26, 2021

Preflight Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

The problem I, that all identity providers are directly attached via connectors. You may use the groups by the groups scope. But this is quite inflexible. In most cases you have no influence to the group naming and you don't want this group namings in your backend code or your frontend. Here coms the roles translation in play

The scope Groups already exists. A new Scope "Roles" is added. When the oidc request contains the scope "Roles", the following logic will be added to any kind of connector.

  1. The user logs in and as result he is able to get the all group, that he is a member of in the using identity provider.
  2. By the connector configuration a new map configuration will translate all incoming groups into a list of roles.
    i.e. the following config:
- Group1:
    - frontend
- Group2:
    - admin
- Group3:
     - frontend
     - admin

if the user is member of the group "Group1" the roles "frontend" are added to the identity.
if the user is member of the group "Group2" the roles "admin" are added to the identity.
if the user is member of the group "Group1" the roles "frontend" and "admin" are added to the identity.

when all scopes are collected, this are distinct set to a list "Roles" inside off the identity of the user.
When a token ( access / id) is generated, a new claim "Roles" is added to the token, that contains the distinct Roles list of the user identity.

Proposed Solution

I already finished an implementation for all connectors. This implementations add the scope Roles to the login and refresh. For each connector a new configuration property "appliedRoles" is added to each connector besides the mock connector. By this you can configure any instance of a connector to add to the user identity a list of roles, that is selected from map[string][]string . By this for any group a list of roles can be configured. All matching groups will be converted to the related roles, that are distinctly added to the token, if the initial login / refresh has been executed in use of the scope "Roles"

Alternatives Considered

No response

Additional Information

This feature is for our project essential and we would like to remove a keycloak as oidc proxy by dex for a bigger cloud platform project. By we do need this transparent layer between groups and roles because we can't define the groups of any identity provider. I'm coding for years in the oidc / java / c environment and I through, this would be a nice feature for dex, that I'm using privately .

The implementation is done, some testing too. Maybe some unit tests should be added. I would push the branch afterwards when I got the access.

@sagikazarmark
Copy link
Member

@nolem I think this is a good idea, but I'd consider waiting for #1635 with the implementation: the config file is already chaotic as it is, so I'd prefer holding back features that doesn't necessarily improve that situation.

We already have a POC implementation abandoned by its original author. I plan to work on that feature after my PTO as it's important for us as well.

@AnirudhPokala
Copy link

@nolem any updates on this feature, role claim as part of token? We are also looking to implement for same feature in our supporting dex connectors, would be helpful if can you point us to any gist or branch of this feature of your implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants