search

dask / dask-gateway

A multi-tenant server for securely deploying and managing Dask clusters.
https://gateway.dask.org/
BSD 3-Clause "New" or "Revised" License
135 stars 87 forks source link

Consider JupyterHub authentication rework #829

Open consideRatio opened 2 months ago

consideRatio commented 2 months ago

Currently the dask-gateway client is reading the user's JUPYTERHUB_API_TOKEN, which then is passed to the dask-gateway-server, which then confirms the jupyterhub api token is associated with a real user via the hub/api/authorizations/token api by using the user's api token.

Drawbacks

  1. dask-gateway clients sends away the user's api token and its used directly - its a course authentication check that gets the full permission of the user (I think) even though dask-gateway server just needed to confirm the user was allowed
  2. there isn't a mechanism to provide some users but not all users access to work with dask-gateway if what dask-gateway-server only checks if the user exists or not

Alternatives

In this jupyterhub documentation I understand that there is a way to implement authentication that ens up requiring the user to have access:services!service=$service-name where service name could be dask-gateway for example (it should be the service name configured with jupyterhub, allowing dask-gateway to interact with jupyterhub in the first place).

Action points

Consider if its reasonable to migrate the existing authentication check to something new that requires users to have a scope of access:services!service=$service-name.