setting up jupyterhub behind shibboleth authentication

[Jakub Moscicki]

We are setting up jupyterhub behind SSO (shibboleth) in our organisation. Is there a shibboleth authentication plugin available for jupyterhub?

If not,  the setup we have in mind is the following: the authentication step and authentication cookies are managed by the fronted web server (apache/mod_shib) which also acts as a reverse proxy to jupyterhub. All the traffic from reverse proxy should be trusted by the jupyterhub the user name comes in a header for each request. The unix users exist locally. What's best way to add such support (as an option) to jupyter hub? Is it in Base Handler? e.g.: https://github.com/jupyter/jupyterhub/blob/498c062ee001d5926b601f67648f1993826852c5/jupyterhub/handlers/base.py#L159

Does this approach make sense? If it does, would you be interested in having such an option integrated in the upstream jupyterhub codebase?

[Kyle Kelley]

While I can't comment about shibboleth, I highly recommend making sure that websockets (through kernel interaction or the terminal) are successfully proxied via Apache. People have had trouble with that in the past and ended up switching to nginx.

--
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/62e28c8a-db35-42a4-aa5a-87ba1acde40f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kyle Kelley (@rgbkrk; lambdaops.com, developer.rackspace.com)

[Andrea Zonca]

Jakub,

not sure if this helps,

Min implemented CILogon authentication in oauthenticator:

https://github.com/jupyter/oauthenticator/blob/master/oauthenticator/cilogon.py

I deployed this and tested authentication with SSO of many UC campuses and

works great.

Cheers,

Andrea

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CA%2BtbMaU5JuMgBhs0P2X%3DtgcAmk4aCvHTGDJpVVUfnPQctBhzGA%40mail.gmail.com.

[Carl Waldbieser]

I am currently working on a REMOTE_USER authenticator [1].  The idea is that you can stick an authenticating proxy in front of Jupyterhub and then it can pass the authenticated user to the hub via an HTTP header (e.g. REMOTE_USER).  I actually planned on doing this for CAS (Central Authentication Service) authentication to the hub.  I have an authenticating CAS proxy project [2] that I recently added websocket support to (see the websocket branch), and I have this working in development.

If you are using Shibboleth Native SP, you could probably use a very similar approach, and have Apache act as the authenticating proxy.  As rgbkrk mentioned, though, you need to make Apache deal with websockets to get the behavior you want.

Are you planning on using Jupyterhub in a federated environment?  I would be interested to know more about that.

Thanks,
Carl Waldbieser

[1] https://github.com/cwaldbieser/jhub_remote_user_authenticator
[2] https://github.com/cwaldbieser/txcasproxy

[Jakub Moscicki]

Hello,

Thank you for useful suggestions. We will report back on our experience. For the moment it looks that REMOTE_USER authenticator for authenticating proxy is the closest to what try to achieve. However, I am not cleat on if jupyterhub would need to set its own cookie rather than using one provided by shibboleth. I would imagine that one reason could be that the jupyter session may last longer then authentication session (to reconnect to the existing notebooks after the auth session expires). We ought to verify that.

For the moment, we do not plan to use federated access with Shibboleth. We assume that all unix users exist locally (from our  LDAP server).

kuba

--

--

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/9239f68e-cbcc-4cd9-92f9-1ded2266c04b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
Best regards,
Kuba

[Carl Waldbieser]

Yes-- the Shib session and your application session are *typically* different.  I suppose you could have an app that relies entirely on Shib for authentication and has no session of its own, but typically you have Shib authenticate the user and then your webapp establishes its own session.  Shib doesn't get involved again unless your webapp session expires.

Thanks,
Carl

[Ed Summers]

Hi Kuba,

On Monday, November 9, 2015 at 3:18:29 AM UTC-5, moscicki wrote:

Thank you for useful suggestions. We will report back on our experience. For the moment it looks that REMOTE_USER authenticator for authenticating proxy is the closest to what try to achieve. However, I am not cleat on if jupyterhub would need to set its own cookie rather than using one provided by shibboleth. I would imagine that one reason could be that the jupyter session may last longer then authentication session (to reconnect to the existing notebooks after the auth session expires). We ought to verify that.

For the moment, we do not plan to use federated access with Shibboleth. We assume that all unix users exist locally (from our  LDAP server).

I was wondering if you came up with an authentication solution for jupyterhub that worked for your situation? Did you give oauthenticator.cilogin a try, or go in another direction?

//Ed