multiple authenticators

[Tim Harsch]

Is it possible to use more than one authenticator in JupyterHub?

Thanks for any guidance,

Tim

[Matthias Bussonnier]

Hi Tim,

As far as I can tell, No; but what is your idea about how multiple
authenticator would work from a UI point of view ?
It should be possible to write an hybrid Authenticator that dispatch
on sub authenticator depending on some conditions; like for example
the domain of an email address. There is possibly some limitation for
now; but we'll be happy to know if you find some; and figure out how
to accommodate for them;

--
Matthias

> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+u...@googlegroups.com.
> To post to this group, send email to jup...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/ff2c50ec-af0e-419d-99a1-4783eba5fa76%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Tim Harsch]

Hi Matthias,

At this stage I am still generating ideas to try and help solve a problem I am trying to address.  I will work more on it today and may have more to discuss on that topic soon.

In the meantime, I am toying with the idea of having two user stores essentially.  Similar to the common concept in LDAP called chaining which is generally useful to organizations.  Translating it to Jupyterhub, let's say you have a corporate LDAP that you want to add access to the new Jupyterhub instance you stood up, but you've already defined all your users using say PAM with local accounts (or Kerberos or JWT or other) and then you want to add an LDAP source.  Generally you feel these users sets are distinct sets and should have similar access.  So, you want primary store to be PAM and then consult LDAP for the second authenticator.

In my case, I am thinking in terms of JWT as the primary and KDC as a secondary, and the policy may need to be an intersection of the user sets, rather than union as I described above.  So if a user is found in JWT and they are found in KDC in some realm, then allow access to the hub.  I'm sure I could probably write a custom authenticator specific to JWT + KDC, but wouldn't it be neat if there were a strategy for chaining authenticators?   I don't know, just some ideas at this point I guess.  

Thanks for your consideration,

Tim

[Carl Waldbieser]

Tim,

In that specific case, you could have the PAM module actually check the local `passwd` database first and then fall back to LDAP.

In your general case, it is possible to write an authenticator that tries one method first, and another method if that one fails, but I don't think there is a general formula for doing that.  For example, authentication like CAS, SAML2, or OpenID may involve redirects and callbacks, and you'd need to keep track of some kind of "conversational state".  I've seen this done by keeping state on the client (browser) and digitally signing the data with secrets from the server to make sure no manipulation is going on at the client.

For authentication methods that don't involve redirects (e.g. local authentication and LDAP), you could simply build a general kind of if/else if ladder.

Thanks,

Carl Waldbieser