Integrating OK Auth into JupyterHub

[yuvipanda]

Right now, students have to authenticate at least twice when logging into datahub.berkeley.edu:

1. Once using Google Auth to log in to JupyterHub
2. Again with ok inline in the notebook.

I'd like to reduce this number to 1.

Options I can think of right now are:

1. Have ability to exchange authenticated Google Auth tokens (which JupyterHub has) for authenticated OK tokens, and then pass the OK tokens into the spawned notebook server
2. Write an OK JupyterHub authenticator, and then pass the OK tokens to the spawned notebook server.

The tokens can be passed as environment variables or a file on a well known path, and the OK client can just read these.

Thoughts?

[Sumukh]

This is on OK server since the first option involves some server changes. If we can find a secure way to do that - I'm not opposed to adding a route for it. (Before #1026 we could have just used the tokens)

2 seems ideal - but JupyterHub only supports having one form of auth so it's an all or nothing deal for the course. If OK goes down - students also can't login to JupyterHub.

[yuvipanda]

Yeah, I agree #2 seems ideal. Do you think OK's uptime would be realistically a problem if we did that? Writing a new JupyterHub authenticator is fairly trivial...

[Sumukh]

I don't think downtime is realistically an issue. We've historically been pretty good about uptime and running a fairly robust HA setup.

99.99% for the last 30 days.

[yuvipanda]

Does OK allow auth only from people who are already enrolled in a course, or is it wider than that? Right now we allow anyone with a berkeley.edu account to log in, and that's great for debugging and what not. Can we keep the same behavior with OK?

[Sumukh]

It allows auth from anyone with a Google account - you make an API request to see what courses they are enrolled in once you get an OK token.

We can look into restricting that to just @berkeley.edu accounts on the JupyterHub authenticator side (depending on how the authenticator is written) or on the OK server side

[yuvipanda]

Yeah, doing that on the JupyterHub side seems sane.

Would anyone already working on OK have time to write the authenticator? It's fairly simple and I can offer help. You can see http://github.com/jupyterhub/oauthenticator for current OAuth related authenticators.

[Sumukh]

I'm happy to write the authenticator - but I might need a few more days to clear my plate of current OK issues. I'll ask around if anyone else is interested though.

It'll need to be timed with a release of a new version of the OK-Client that can pickup on this environment variable.

[yuvipanda]

One thing having an OK authenticator might let us do is say things like 'let anyone with a berkeley.edu in, and also let people who are enrolled in course X in', which is something @papajohn wants I think (to manage guest access?)

[yuvipanda]

And just to remember - let's make sure to test against berkeley-dsep-infra/jupyterhub-k8s#99 too when this authenticator is built

[Sumukh]

Update: I talked with some of the folks from the https://datasci.berkeley.edu/dsep-projects infrastructure team and they seem interested in writing the authenticator. I think they'll reach out to @yuvipanda when they have questions

[yuvipanda]

Deliverables for marking this as done:

JupyterHub Authenticator for OK that uses OK's OAuth.

1. Users can log into JupyterHub with OK
2. There are tests for users logging into JupyterHub with OK
3. The authenticator saves an OK authentication token in it's state
4. We change spawner config to put the OK authentication token into the spawned user's configuration
5. We change ok-client to read the authentication token from the environment variable we put it in.

If we have time after, we might consider working on limiting login based on which courses students are enrolled in. But that's not a primary requirement right now.

I just wrote this with @stevenwuyinze, and he's going to start working on this now!

[stevenwuyinze]

Update: our team members have installed and tested out toy Google OAuth of JupyterHub locally.
We will begin tracking features and progress on PivotalTracker