cwaldbieser / jhub_remote_user_authenticator

REMOTE_USER authenticator for Jupyterhub.
GNU General Public License v3.0
41 stars 36 forks source link

Apache and Shibboleth #18

Open ghost opened 4 years ago

ghost commented 4 years ago

Has anyone used this authenticator in combination with Shibboleth and Apache as a proxy? Do you have any advice on how to get this working?

Maybe someone can point me to some documentation or how-to-guide. Or maybe someone can think of an easier way to do this. I appreciate any help.

cwaldbieser commented 4 years ago

You would probably get the best advice by posting to the Shibboleth mailing list: https://www.shibboleth.net/community/lists/

LukasMueller187 commented 4 years ago

@Coding-Composer We just managed to do it. Advice still needed?

cwseys commented 4 years ago

@LukasMueller187 We just managed to do it. Advice still needed?

Yes! We have a working version with jupyterhub 0.9.6, but upgrading to 1.1.0 breaks the "Access Server" option (for admins to access notebooks). If you're still about, would love to have help.

LukasMueller187 commented 4 years ago

@lickdragon I'm glad to help. Where do you need advice exactly? You do have Shibboleth authentication already up and running?

cwseys commented 4 years ago

@lickdragon https://github.com/lickdragon I'm glad to help. Where do you need advice exactly? You do have Shibboleth authentication already up and running?

That would be great!

Yes, in Jupyterhub 0.9.6 everything works as expected.

But using exactly the same config files, jupyterhub 1.1.0 (also 1.0.0b) mostly works. E.g. a user can use Shibboleth to log in and access their notebook.

The feature lacking is that an admin can no longer access another user's running notebook. ('Control Panel -> Admin -> access server'). (Do you have this working?)

Instead an access page is displayed. " Authorize access A service is attempting to authorize with your JupyterHub account

Server at /user/amadrid/ (oauth URL: /user/amadrid/oauth_callback) would like permission to identify you. It will not be able to take actions on your behalf. "

Something changed in the jupyterhub behavior, so possibly this is a jupyterhub problem, not a jhub_remote_user problem. But maybe something needs to be adapted in our config or in jhub_remote_users. I don't know.

Here's our apache config:

<VirtualHost :80> ServerName "jupyterhub5.fqdn" Redirect permanent / https://jupyterhub5.fqdn/ <VirtualHost :443> ServerName "jupyterhub5.fqdn" ProxyPass /Shibboleth.sso ! ProxyPassReverse /Shibboleth.sso ! ProxyPass / http://127.0.0.1:8000/ ProxyPassReverse / http://127.0.0.1:8000/ <Proxy "*"> Header edit Origin "jupyterhub5.fqdn" 127.0.0.1:8000 RequestHeader edit Origin "jupyterhub5.fqdn" 127.0.0.1:8000 Header edit Referer "jupyterhub5.fqdn" 127.0.0.1:8000 RequestHeader edit Referer "jupyterhub5.fqdn" 127.0.0.1:8000

proxy websockets

     <Location ~ 

"/(user/[^/]*)/(api/kernels/[^/]+/channels|terminals/websocket)/?"> ProxyPass ws://127.0.0.1:8000 ProxyPassReverse ws://127.0.0.1:8000

authentication interferes with websockets and isn't needed,

so only apply it to /hub <Location ~ "^/hub"> AuthType shibboleth ShibRequestSetting applicationId "jupyterhub5.fqdn" ShibRequestSetting requireSession 1 Require valid-user Allow from all

       RewriteEngine on
       RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER},NS]
       RequestHeader set REMOTE_USER %{PROXY_USER}e
     </Location>
     Include /etc/apache2/star.fqdn_ssl.conf