User managment in JupyterHub (authorization)

Hi all,

this is a general question to find different ways how we could solve our problem.

We are currently setting up a Jupyterhub instance which should be used for educational purpose and host multiple courses.
Additionally every course provides an image which can be selected when spawning the user server.

Currently Authentication (user login over oauth) and spawning user servers works fine.

Open questions we have:

  • (authorization) we would like that students can only see images that are correlated to their courses, is there something in Jupyterhub (except adding hardcoded roles into the config)? Would it be recommended to handle it via an extra service?
  • (available images) update the list of available images when new ones are added to a registry (currently they are hardcoded in the config)

Do you have any insight, experiences, tips or ideas how we could solve the above mentioned questions?

We want to avoid shutting down the Hub when changing available images or authorizing new students.

Would appreciate any help or links to documentation!

Thanks in advance!

This should be possible. You can definitely store this information outside JupyterHub in order to make it updateable without modifications to the Hub. The simplest version could be a file (yaml or whatever) that stores this information, and is loaded every time you compute the image list for a given page view. That means the methods you use (e.g. options_form) need to be callables, not static config, so they are computed every time. Then to update your images, edit this file and it will affect all future launches.

You can see the discussion following here for some examples of per-user options forms.

This could also be an external service accessed over HTTP, etc. instead of a file, but the logic ends up the same. Whatever suits your deployment needs.

The most jupyterhub-centric way to do this is combining Spawner.group_overrides with Authenticator.manage_groups, where your Authenticator manages the groups a user is in, and the Spawner group_overrides uses group membership to modify things like the profile list or other fields where you handle image choices. But you don’t have to do it that way.