Add option to include group roles in OpenID Connect application response
Problem to solve
Currently, the names of the groups a user is a member of is shared with the application client when OpenID Connect is configured for an application using the openid
scope. While this is great, it would be even better if you could optionally include (append) the group role the user has to provide better information to consuming clients who want to use this feature as an authorization source and not just an authentication source.
Intended users
Anyone who uses the openid scope to provide authentication and authorization to other applications.
Further details
For example, we want to use GitLab as the identity provider for Kubernetes clusters, using the GitLab groups a user is a member of to assign RBAC roles for associated namespaces etc, but we need to distinguish roles to give the correct permissions. A Developer might be able to have some read-only permissions on the Kubernetes resources, while a Maintainer or Owner should have full permissions (and a Reporter might have no permissions). With the current limitation of just the group name, we'd have to use the least common permissions for the group and then add individual permissions above that.
Proposal
I envision adding an additional checkbox to the New/Edit Application screens, perhaps indented beneath the 'openid' scope checkbox that could be greyed out or hidden until the openid scope is selected. It would inform the user that optionally checking the box would append roles to the end of the group names.
For example, a user who is assigned the Developer role for 'group1' and the Maintainer role for 'group1/subgroup-2' would have the following groups returned by GitLab: 'group1-developer' and 'group1/subgroup-2-maintainer'.
I'm not sure if '-role' is the best option to append here, but given that all of the current roles are single words, it should be easy enough for an application to parse off the last dash and word to get the role if it needs to.
For the applications API endpoint (and underlying data model for the UI), I'm not sure what the best solution would be. You could add a new scope
option like 'openid_with_groups' or create a new attribute that was 'with_groups' or something more generic that could be used for other features that might be added later like 'options' that takes a nested json object.
Permissions and Security
Permissions would not need to be changed.
For security, I don't believe that sharing the group roles in addition to just membership would be problematic given that users understand that implication when choosing the option.
Documentation
The OpenID Connect documentation would need to be updated to include an explanation of what adding the group roles would do to the groups array returned by GitLab, e.g. that it will concatenate a '-role' to the end of all group names.
The API documentation would need to be updated accordingly based on how the problem was solved. It currently links to Using GitLab as an authentication provider for more information, which itself could probably use additional documentation. For example, it just suggests that other than read_user
and api
, 'there are many more scopes available.' Providing a list of the valid scopes along with a description and links to other relevant documentation would be helpful.
Testing
Testing should expand what's being used for the openid scope to ensure that group roles are being appended to group memberships during the oidc process
What does success look like, and how can we measure that?
Success is having group roles included in the groups array returned by the openid application scope with minimal impact on additional response time ( < 50ms more on average?)