IIS 7.5 Server behind an F5 Reverse Proxy

[Meiselman, Ellen]

Hi, 

Scott, thank you for your previous help. I got the handlers (Metadata, Session, etc) working thanks to your suggestions. It now redirects to the login screen as it should.
 
To recap: I have an SP behind a reverse proxy that has mapped a path (https://proxyserver.com/content/) to the root of our IIS webserver (https://contentserver.com).  

Browsing to  https://proxyserver.com/content/somepage.htm now redirects to the SAML login screen as it should.

The problem: Upon logging in, it goes into a loop. Looping behavior that I've seen before was always caused by mismatched https/http cookie issues, but I haven't been able to figure out what the cause is here yet. 

I need help with the best practice for debugging the looping behavior. I'm not sure what to look for in particular.

Right now my settings in shibboleth2.xml are:

 <Site id="1" name="proxyserver.com/content" />  

------

<RequestMap>
 	<Host name="proxyserver.com/content" authType="shibboleth" requireSession="true"/>    
 </RequestMap>
------

<ApplicationDefaults entityID="https://proxyserver.com/content" homeURL="https://proxyserver.com/content/iisstart.htm"
                         REMOTE_USER="eppn persistent-id targeted-id">
       
        <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" handlerURL="/content/Shibboleth.sso"
                  checkAddress="false" handlerSSL="true" cookieProps="https">

------

           <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

            <!-- Status reporting service. -->
            <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>

            <!-- Session diagnostic service. -->
            <Handler type="Session" Location="/Session" showAttributeValues="true"/>

            <!-- JSON feed of discovery information. -->
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>


Thank you very much for your help. 

Ellen

______________________________
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 20, 2014, at 1:07 PM, Cantor, Scott wrote:

> On 8/20/14, 1:00 PM, "Meiselman, Ellen" <emeiselm at med.umich.edu> wrote:
>> 
>> They can't, unfortunately. The root of the domain proxyserver.com is
>> being used for the LMS application. The /content/ subdirectory is being
>> used for our SCORM content which has to use the same domain, protocol,
>> port, etc. so that javascript can communicate across frames.
> 
> The first mistake was really using frames then, they should be banned at
> this point.
> 
>> So that means I still probably have a path problem with my setting for
>> the metadata handler.
> 
> No, it means your system doesn't know what it's named and how it's being
> accessed. When you virtualize a system, the web server needs extensive
> features to support that. IIS has none of them, so at a basic level it
> does not support load balancers. If you can't tell a web server that its
> logical settings are different from its physical settings, then you can't
> virtualize it unless all the applications running on it are themselves
> broken and ignore the web server's own reporting of the values to
> applications.
> 
> The SP compensates for that imperfectly through the Site mappings in its
> own configuration, and you haven't set those mappings up correctly to
> report the virtualized scheme, port, or hostname, or all three.
> 
> The metadata handler is irrelevant anyway, it's for providing example
> metadata, not for production use. None of your handlers are going to work,
> and the assertion consumer service not working means the SP doesn't work
> period.
> 
> -- 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