Have a robust set of authentication methods that can serve different users

[GeorgianaElena]

Background

We are using Auth0 to provide authentication for the pilot-hubs. Auth0 can be configured with different connections that users can authenticate with and at the time we're using either Google, GitHub. For JupyterHub to understand this, we're "translating" the auht0 connection setup and configure a GenericOAuthenticator..

In theory we support every provider that Auth0 supports, but we’ve currently only tested google-oauth2 and github. Different GenericOAtuthenticator config options settings might be needed to support the others.

We should however explore whether or not we can allow different authentication methods for a hub based on user needs (relevant issue: #228).

Expected timeline

To the question can we provide authentication via multiple OAuth providers on the same hub with minimal configuration changes?, I expect we can come up with a yes or no answer in less than 2 weeks.

However, if this requires significant changes (like writing our own JupyterHub authenticator that wraps multiple existing OAuthenticators), this might extend over a couple of months.

I suggest keeping this issue opened for about 2 months and update its timeline once we come up with a plan.

Steps to complete this goal

• Support ORCID auth provider (Many folks in academia use this as a way to link identities across journals, etc. It's also free to register. (Support using ORCID as authentication #290)
  • Document ORCID auth provider:
    • Hub admin documentation
    • 2i2c engineer documentation
• Add username / password based auth Add manual username/password configuration with Auth0 #66
  • Document username / password auth:
    • Hub admin documentation
    • 2i2c engineer documentation
• Support CILogon (Enable authentication via CILogon #315)
  • Document CILogon auth provider:
    • Hub admin documentation
    • 2i2c engineer documentation
• Investigate how we can restrict access based on group membership via auth0. For example, GitHub organization / team membership, or Google Groups membership.

[yuvipanda]

\o/ Thanks for filing this, @GeorgianaElena.

Multiple authentication methods cause some issues around identity mapping. For example, how would I know that yuvipanda on GitHub is the same as [email protected]? A user would need to remember exactly which authentication method they used to sign in, and that is not the most ideal user experience. One way around that is to prefix all usernames with their 'provider' - so something like gh:yuvipanda and google:[email protected]. Otherwise, someone with, say, a twitter account at yuvipanda could pretend to be same as yuvipanda on github. This collision is something we'd need to solve.

In the meantime, I think it would be very helpful to have at least these two additional auth providers:

• ORCID. Many folks in academia use this as a way to link identities across journals, etc. It's also free to register.
• CILogon supports a lot of universities! So users can sign into CILogon with their university credentials, and we can then filter people based on university identity. They support thousands of such connectors, and we can benefit from that. They even have documentation on integration with auth0.

We should also investigate how we can restrict access based on group membership via auth0. For example, GitHub organization / team membership, or Google Groups membership. I am not 100% sure how to do this with auth0 :|

[choldgraf]

Hey all - I am starting to think that we should define a pipeline around pull requests for new features. A couple of times now we have merged in functionality but I don't see any indication of this in the documentation. (latest I noticed was the ORCID auth) I think this is a practice we will regret very quickly if we don't follow it diligently.

Can we define "support a feature" as a combination of "Make the feature possible + document its functionality and how to use it"? So we don't tick-off the boxes in the top-level comment until both of those are accomplished?

I am not sure the best way to accomplish this, but maybe a modification to the issue template or adding a PR template? (for now I've just added "document ORCID OAuth" above). What do you think?

[yuvipanda]

2i2c-org/docs#55 has documentation around ORCID, but is missing SRE style docs on 'how to' do it. We should definitely make sure each authentication method we add is documented.

[yuvipanda]

Closing this in favor of more specific issues:

• Enable authentication via CILogon #315
• Support OAuthenticator for our hubs #625
• Authenticate users with GitHub Teams membership in Pangeo Hub #598