ShibRequestSetting in nginx-http-shibboleth

[nick-wellinghoff-sp]

Description of Issue/Question

David, thank you for all your work on this module. It works great!

Is there a method to match the functionality of ShibRequestSetting in nginx-http-shibboleth? I would like to use ShibRequestSetting to set the applicationId the authorization will use outlined in this document.

https://wiki.library.ucsf.edu/display/IAM/Steps+to+configure+multiple+context+in+Shib+SP

This will allow a shib user to host many websites with multiple SP configurations off one reverse proxy. Very useful.

Do we set FastCGI attributes to do this? If so how? And if not where would you recommend in your source I look to make an extension to support this use case?

Thanks! Nick

Versions and Systems

(nginx -V, shibd -v (and compile options), OS type and version) On all the latest versions of nginx and shibd. Debian Jessie.

[davidjb]

Thanks @nick-wellinghoff-sp, it's turned out really well. As for your question, good news -- it's all possible already.

With the FastCGI Shibboleth SP, its configuration comes from the <RequestMapper> within shibboleth2.xml, rather than the web server's "native" commands (like they can do in Apache). So this means if you were to put the configuration from https://wiki.library.ucsf.edu/display/IAM/Steps+to+configure+multiple+context+in+Shib+SP#StepstoconfiguremultiplecontextinShibSP-ShibbolethSPconfiguration (step 2) into your shibboleth2.xml file, it'd work with the existing nginx/FastCGI stack. That UCSF example shows multiple applications on one hostname, but you can add multiple <Host> (or <HostRegex> etc) entities into shibboleth.xml to serve multiple hostnames/paths/applications etc from the same server. Definitely read our documentation on configuring secured paths.

That said, if you look at https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapper, you'll see the difference between the two types of RequestMapper. There's type="Native" (which is what's used in the UCSF docs) which allows both native web server commands and XML configuration to config Shibboleth, and type="XML", which permits just the XML-based configuration. I use the latter (see my example) as nginx/FastCGI don't use native commands (or .htaccess); and the Shibboleth wiki mentions there's efficiency to be gained (however small).

Also, for what it's worth, the configuration at https://wiki.library.ucsf.edu/display/IAM/Steps+to+configure+multiple+context+in+Shib+SP repeats itself -- the ShibRequestSetting lines in Apache match what's already set in the <RequestMapper> in shibboleth2.xml. According to Shibboleth's docs:

The native commands override any XML-based attributes. so the UCSF page's configuration is overriding the XML-based config with the same values set in Apache.

[nick-wellinghoff-sp]

David,

Thanks for the thorough response. I was able to get it all working. One key piece of information that is obvious to nginx pros or when you finally understand how everything is moving around is that you have to add another Shibboleth.sso route to your nginx config for each additional sub route you add in the request mapper.

    #FastCGI responder
    location /Shibboleth.sso {
        include fastcgi_params;
        fastcgi_pass unix:/tmp/shibresponder.sock;
    }

    location /app2/Shibboleth.sso {
        include fastcgi_params;
        fastcgi_pass unix:/tmp/shibresponder.sock;
    }

or add a regex path that matches all /.+/Shibboleth.sso such that your additional handler urls get routed to shib instead of your app path. Just a little gotcha it took me a good 20 minutes to realize.

Thanks again! Nick

[davidjb]

No problem. Glad you got it sorted!

If you didn't want to add extra responder location blocks, you could potentially change your handlerURL in shibboleth2.xml to being absolute (eg https://example.com/Shibboleth.sso; see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions#NativeSPSessions-HandlersandEndpointConstruction) -- and then each of your apps would use the same /Shibboleth.sso block.

[nick-wellinghoff-sp]

Great point.