fmigneault
commented
5 years ago @tlvu
TL;DR not currently
For point (1), once Magpie has logged in to Github to find your matching Magpie user, it doesn't preserve the credentials nor the Github token internally for security reasons. It simply returns you the Magpie token allowing you to interact with it as this logged user on future requests. So it is up to you to provide all necessary tokens (Mapgie, Github, JupiterHub, whatever...) so that each sub-component of the request's specific connections can be accessed. Magpie's job is not to validate incoming request access control, this is Twitcher's job. Magpie only manages the permissions of a specific Magpie user that tells Twitcher how to execute the desired access control.
For (2), the Authorization: bearer <token> header format is supported for WSO2 external provider via Magpie Adapter OWSSecurity, but you cannot use it directly as is to add JSONWebToken Authenticator as a new provider because it is not configured in Authomatic config. If the config was updated to allow this new external provider, then Twitcher requests using the above Magpie Adapter should work. You could also directly use a WSO2 account as an external signin provider for JupyterHub (if it allows that?), and then both Magpie/JupyterHub would be using this WSO2 user via Twitcher's request access control.
There is a plan to integrate more user roles in Magpie (#170), which would help making it an external signin provider for others, but it's far from being implemented for the moment.
In the short term, it should be easier to execute your requests with both the Magpie token and the JupyterHub token in the request cookies to ensure login works in both places.
So I am looking for a way to have "single sign-on and access control" between all the services of PAVICS and JupyterHub. Magpie is currently responsible for that single sign-on and access control part. The access control part is important too because for some Jupyter users we might want to limit their access to some datasets on Thredds for example.
So if we need to add JupyterHub to the mix, JupyterHub must integrate with Magpie.
So if my assumptions above are correct, for JupyterHub to integrate with Magpie to provide a single sign-on user experience, we have the following options:
both Magpie and JupyterHub uses the same external signin provider so the single sign-on user experience is achieved because the user is only required to login once to that external signin provider. Magpie then only provide the access control feature, the authentication being handled by the external signin provider.
JupyterHub somehow can "see and use" the authorization token from Magpie (Magpie acting as external signin provider to JupyterHub) so the single sign-on user experience is achieved because the user is only required to login once to Magpie as an internal user to Magpie (not using external signin provider with Magpie). Magpie in this scenario provide both authentication and access control.
As seen in #171 and #172 option 1 is not working great so far.
As a backup plan I would like to explore option 2. From the list of all the possible authenticators for JupyterHub here https://github.com/jupyterhub/jupyterhub/wiki/Authenticators the following subset looks interesting, could anyone of them work with Magpie?
JSONWebToken Authenticator (For Authenticating/Authorising users based on a JSONWebToken forwarded in an
Authorization: bearer <token>header.)REMOTE_USER Authenticator (For when intermediate login infrastructure such as Apache offloads authentication and forwards REMOTE_USER header.)
CASAuthenticator for CAS Single Sign-on SSO