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 On Monday, October 2, 2017 at 1:34:13 PM UTC-4, Tim Harsch wrote: > > 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 > > > On Monday, October 2, 2017 at 9:10:20 AM UTC-7, Matthias Bussonnier wrote: >> >> 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 >> >> >> >> On Mon, Oct 2, 2017 at 8:52 AM, Tim Harsch <[email protected]> wrote: >> > Is it possible to use more than one authenticator in JupyterHub? >> > >> > Thanks for any guidance, >> > Tim >> > >> > -- >> > 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 [email protected]. >> > To post to this group, send email to [email protected]. >> > 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. >> > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/a5bfbbf4-d8b0-4e26-8a79-d8c24c69260c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
