[ENH] - Keycloak Group attributes to control JupyterLab profile access

[danlester]

Feature description

This functionality has been dropped in the recent refactor.

If a Keycloak group had a profile attribute containing a list of JupyterLab profiles then members of that group would be able to access the profiles. This check only came into effect for profiles defined with groups: (which could be empty) in the qhub-config.yaml file. That choice was because profiles defined with no groups: (or users:) would be available to all users - i.e. no access control - so this ability to override dynamically by setting Keycloak group attributes is not wanted for those groups.

I would like to reinstate this functionality. It is possible that some usage of roles in keycloak would be better, but as a short term solution at least, this functionality can be easily reinstated by adding a mapper to the jupyterhub client as follows:

We would also need to reinstate the code that checks for this in jupyterhub_config.py or similar.

I propose we change the attribute name from profiles to jupyterlabprofiles though.

Value and/or benefit

This allows profiles to be assigned to groups dynamically using Keycloak without a full redeploy.

Anything else?

No response

[costrouc]

@danlester I think this is great functionality to have and we could control dask profiles the same way. I was able to get this working as a test but haven't actually implemented it.

Settings some group and user attributes

I've used profiles but I agree we should use a more specific name like jupyterlabprofiles.

Next set a mapper on the jupyterhub oauth client

Testing it within keycloak

[danlester]

Yes, that's the same as the approach I was suggesting. But I think you need to specify lists like this:

profile1##profile2

In my tests, the mapper merged as hoped - just one long list of all profiles (not duplicated).

[costrouc]

Oh awesome much better didn't know about that option https://stackoverflow.com/questions/61132928/keycloak-user-attributes-with-multiple-values-list

[costrouc]

Also longer term I think this is the correct way we should encourage admins to manage profile access. I'd be in favor of dropping users and groups to make the qhub-config.yaml simpler. And not require redeploys for actions like this.

[danlester]

Actually, the behavior is getting very confusing once we mix all these ways to control permissions. I will add a field called access that can be one of [all (default), keycloak, yaml]

If access: all then every since user has access and groups and users must NOT exist in the profile definition in the yaml file.

If access: keycloak then again groups and users must NOT exist in the profile definition in the yaml file but access will instead be granted to any Keycloak user with jupyterlabprofiles attributes that include that profile name. This means that if no Keycloak attributes are created for any user/group then no-one has access to that profile.

If access: yaml then groups or users are each optional and access is granted to anyone who is a member of a group listed or who is listed in users directly. (Keycloak attributes of jupyterlabprofiles are ignored in this case.) If users and groups are both missing or empty then no-one has access to that profile.

[danlester]

keycloak upgrade will have to work its way through this.

Basically if a profile has any groups or users field it should be turned to access: yaml. If it has neither field then it should become access: all.