IIS 7.5 Server behind an F5 Reverse Proxy

[Cantor, Scott]

On 8/26/14, 5:26 PM, "Meiselman, Ellen" <emeiselm at med.umich.edu> wrote:
>
>______________________________
>Line 112. https://reverseproxy.com/content/Shibboleth.sso/SAML2/POST

For that to work, you'd have to have a handlerURL on the SP of
/content/Shibboleth.sso. In addition, the request to that server had
better be for /content/Shibboleth.sso/SAML2/POST. If it's not, the SP
won't handle it, and even if it did, it wouldn't match the URL that's
embedded inside the message from the IdP and will be rejected. If it's
/content on the front-end, it has to be /content on the back-end.

>Note that a new _shibstate cookie is set at this spot with a new number
>appended to its name. Its value is now /content//Shibboleth.sso/SAML/POST

That's because your SP doesn't believe that that is the location of its
handlers, *and* it is being told to protect all URLs with /content in
them. Combine the two and it sees that as a protected resource and issues
a request for a login. You don't need to see a loop to see that, just
access /content/Shibboleth.sso/Foo and when that redirects to the IdP, you
know you have an unworkable system.

The only way the SP will exempt URLs that match protection rules is if
they're for its handlers, and it determines that using the handlerURL
setting.

>One thing we noticed today in the wiki instructions for Reverse Proxy:
>
>* Note that the path (/secure) to the requested resource is set by the
>Shibboleth SP and hence is specific to the protected resource on the web
>server. This mandates that the proxy either proxies the resource with the
>exact same path (/secure to /secure), or that the proxy is able to
>rewrite HTTP resonse headers (e.g. the ones containing
> the relayState) before returning results to the client.
>
>                
>https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy
>
>
>We're mapping /content to /   (webroot)  So that could be one problem at
>least.

It is. You can't do that. The suggestion above won't help either. That
might work if the content URLs were the ones with the mismatched paths,
but you can't do that with the handlers. The message from the IdP will
contain the URL to the proxy, and if that includes a path, the same path
has to be in the request to the back-end server as seen by the SP or it's
going to reject the message.

You can rewrite cookies and RelayState, but you can't rewrite a signed
message.

So full stop, you can't do it.

-- Scott