Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider JupyterHub authentication rework #829

Open
consideRatio opened this issue May 7, 2024 · 0 comments
Open

Consider JupyterHub authentication rework #829

consideRatio opened this issue May 7, 2024 · 0 comments
Labels

Comments

@consideRatio
Copy link
Collaborator

consideRatio commented May 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant