Mapping OIDC groups to INCEpTION's internal roles

[kzgrzendek]

Hello,

I would like to suggest a feature regarding the mapping of OIDC/OAUTH2 groups (when this authentication mode is enabled) to the internal roles of INCEpTION (ADMIN, USER, etc.)

Context

I'm working for the Greater Paris University Hospitals, and we would like to propose INCEpTION as our go-to text annotation tool for our users, as part of our 'Health Data Warehouse' offer (link content in French only, unfortunately).

As you can guess, we are tied by very strict legal and industrial obligation, one of them being the obligation to federate the authentication and authorization of our userbase when we provide services.

This implicates that the applications we're deploying, if they need 'internal roles', should be able to map those with pre-existing groups defined in our SSO solution (Keycloak, in our case).

The go-to standard for doing that being to use OIDC/OAUTH2 to fetch those groups in the user's token or with the userInfo endpoint, that's the reason why I'm proposing this feature, and I guess we're not the only one with those obligations.

Description of the feature

If we simply look at a solution like JupyterHub, we can see that its OIDC module is proposing to set :

• The name of the claim containing the groups (c.GenericOAuthenticator.claim_groups_key)
• The groups allowed as users (c.GenericOAuthenticator.allowed_group)
• The groups allowed as admins (c.GenericOAuthenticator.admin_groups)

Implicitly, all users not members of those groups are denied by the application.

Edge cases to bear in mind

I can think of a few edge cases, but you're welcome to add yours as well :

• If a user is in several groups, granting him different access level to the application, he should have the highest possible access level
  • eg, if a user can be mapped to USER and ADMIN groups, he should be mapped as ADMIN (unless INCEpTION supports having users in several groups!)
• If a user can't be mapped to any group, he should have his access denied (returning à HTTP 403 code)
• If a user is promoted to a group, it should be reflected in the application
  • eg, if a user was in an group mapped to USER, and is now in a group mapped to ADMIN, he should appear as an ADMIN in INCEpTION, and no more as a USER

I'm hoping you'll consider this feature, and am of course willing to discuss about it :)

Thank you