IIS 7.5 Server behind an F5 Reverse Proxy

[Meiselman, Ellen]

Hi Scott, 

I thought I'd report back because we had unexpected success even with our mucked-up reverse proxy mapping. Sorry this is long but I am trying to explain exactly what we did.  I have two questions at the end.



After your last email I put in a ticket to the cloud vendor to change our reverse proxy mapping to what is recommended. However any sort of change typically takes them 2 weeks, so we had time to experiment with the reverse proxy mapping the way it was.

To recap, the issue was that because we have a mapping from a path "/content/" on the reverse proxy server to the root of our SP content server, the paths in the signed statement would include the path /content/ which did not exist on the back end SP server.

     https://proxyserver.com/content/ 
maps to 
     https://contentserver.com



So, we tried fixing the problem from the back end which is the only side we can experiment with quickly. 

We added a virtual directory called "/content/" to the SP content server which pointed to a real directory at the root of the server then added another directory inside it "ct" that points to the resources directory. 

     The virtual directory  /content/ on the content server points to \webroot\directory\

     The virtual directory  /content/ct/ points to E:\path\to\learningmodules\

At that point the looping stopped immediately for the first time. However it was not entirely working. 

When I would try to access a resource:

     https://proxyserver.com/content/ct/resource.htm

it would redirect to the web root 
     https://proxyserver.com/content/
 
So I assumed it wasn't working. Tried clearing cookies, restarting browsers, restarting IIS, restarting Shib service, etc. Then our out-of-town consultant suddenly told me it was consistently working for him on multiple browsers! But it continued to fail for me at the office. When I got home, I tried again, and this time it worked consistently. At the office it seemed not to work for me but did for some people.

 Based on comparing the headers on working and non-working servers, we made a few more changes to shibboleth2.xml - mainly adding explicitly stated 443 port to the hostname

<Site id="1" name="proxyserver.com:443/content" scheme="https" port="443"/>

<Host name="proxyserver.com:443/content" authType="shibboleth" requireSession="false" scheme="https" port="443">  
             	 <Path name="ct" authType="shibboleth" requireSession="true"/>

Then I left for vacation, assuming it was still unstable, since it did not appear to work at all for my office computer .

When I got back the consultant was telling me that it was totally working. I had everyone on my team test both at the office and at home and it just works. At that point I halted the reverse proxy change request. 


My two questions are:

1. When I got back to the office after vacation it STILL did not appear to work on my office computer! Only mine. Everyone else was working.  I cleared all cookies from the browser, cleared the cache, restarted the browser, but it still redirected to web root. Then I restarted the computer and it started working consistently for me. What caused this if not a cookie? We are starting to think that perhaps forms auto-fill was auto-filling an old incorrect signed statement into the form that is POSTed in the background back to the SP. 

I need to understand because this sort of false result can make it very difficult to troubleshoot.


2. Is there any reason I should still go forward with changing the reverse proxy mapping that I halted? 
https://proxyserver.com/content/ ==> https://contentserver.com/content/  


Thanks!




______________________________
Ellen Meiselman
University of Michigan Health System
MLearning
NCRC
2800 Plymouth Rd. 
Building 200, Rm 207
Ann Arbor, MI 48109-2800
E-Mail:  emeiselm at umich.edu
Phone (734) 936-2334

On Aug 26, 2014, at 6:16 PM, Cantor, Scott wrote:

> 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
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues