-
Notifications
You must be signed in to change notification settings - Fork 7
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
jwt #119
jwt #119
Conversation
Lots of hardcoded stuff and assumptions, but works as expected. It can be run as a service with a config like this ``` c.JupyterHub.load_roles = [ { "name": "jwt", "scopes": [ "read:users:activity", # read user last_activity "servers", # start and stop servers "admin:users", # needed if culling idle users as well ], }, { "name": "user", "scopes": ["access:services", "self"], }, ] c.JupyterHub.services = [ { "name": "jwt", "url": "http://localhost:1984/", # any secret >8 characters, you'll use api_token to # authenticate api requests to the hub from your service "api_token": "super-secret", } ] ``` and then start the service: ``` fastapi dev --port 1984 api_wrapper.py ```
Also remove some unneeded code
This is ready for a first review and then deployment in devel/staging. We can refine it later as we test it out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'll leave the testing to Frantisek , but it looks very good to me! ( with the limitations that you have already mentioned)
I'm merging so we have new docker images and we can properly test |
Summary
JWT authentication and an API wrapper capable of from a JWT token call the hub API with a valid internal hub token and return results.
The JWT authentication extends the
egiauthenticator
with a new handler listening at/jwt_login
that when sent a valid JWT token it will authenticate the user as with the regular code grant based authentication and return a JSON like this:This could be used by an API client directly to perform any subsequent calls.
In the EOSC procurement node we add an additional wrapper so the client is not aware of the internal hub token. This wrapper will forward any call to the hub API and will attempt to authenticate with a JWT and use the returned token for the API call. The wrapper is a simple fastAPI application that can be run as a service of the Hub:
What's missing:
Related issue :