Hi Scott,<div> To follow-up on this conversation. I don't fully understand your explanation but we were able to get the reverse proxy with Shibboleth IDP to work using the following environment. So for the Shib User archives here's how it works:</div>
<div><br></div><div>1. Apache2 Reverse Proxy Server at host <a href="https://idp.example.edu" target="_blank">https://idp.example.edu</a></div><div>2. Internal Tomcat server at <a href="http://shib.example.edu" target="_blank">shib.example.edu</a> with SSL setup as 8443 and Shibboleth WAR installed as ROOT.</div>
<div><br></div><div><a href="http://idp.example.edu" target="_blank">idp.example.edu</a> setup with the follow proxying directives (next to its other virtualhost configuration):</div><div><br></div><div><font face="courier new, monospace">SSLProxyEngine on</font></div>
<div><font face="courier new, monospace">ProxyPreserveHost on</font></div><div><font face="courier new, monospace">ProxyPass / <a href="http://shib.example.edu:8443/" target="_blank">shib.example.edu:8443/</a></font></div>
<div><font face="courier new, monospace">ProxyPassReverse / <a href="http://shib.example.edu:8443/" target="_blank">shib.example.edu:8443/</a></font></div>
<div><br></div><div>In order for this setup to work the front-facing host name (<a href="http://idp.example.edu" target="_blank">idp.example.edu</a>) must be in the IDP's metadata SAML section so that Service Providers know how to message back and forth with Shibboleth through the front-facing server URL. However, the proxy to the internal host (<a href="http://shib.example.edu" target="_blank">shib.example.edu</a>) will rewrite the host name URL when it is communicated between <a href="http://idp.example.edu" target="_blank">idp.example.edu</a> and <a href="http://shib.example.edu" target="_blank">shib.example.edu</a>. The directive <font face="courier new, monospace">ProxyPreserveHost</font> is turned on so that the host name is left unchanged when it arrives at <a href="http://shib.example.edu" target="_blank">shib.example.edu</a>. Under normal circumstances we use SSL encryption at the front-facing server and clear text communication to the proxied host because it's already in a safe sandbox but even with <font face="courier new, monospace">ProxyPreserveHost</font> turned on Shib recognizes that the endpoint URL is HTTP when it arrives at <a href="http://shib.example.edu" target="_blank">shib.example.edu</a> and not HTTPS which it expects (causing a SAML EndPoint URL mismatch). So it was necessary to setup SSL communication between the front-facing server and its proxied host in order to mimic the HTTPS URL and match the expected EndPoint URL for SAML.</div>
<div>
<font face="tahoma, sans-serif"><div><font face="tahoma, sans-serif"><br></font></div>Joshua Riffle</font><div><font face="tahoma, sans-serif">Software Engineer<br></font><div><font color="#CC0000" face="tahoma, sans-serif"><b>Azusa Pacific University</b></font></div>
</div><br><div class="gmail_quote">On Mon, Jul 23, 2012 at 12:56 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 7/23/12 3:52 PM, "Joshua Riffle" <<a href="mailto:jriffle@apu.edu" target="_blank">jriffle@apu.edu</a>> wrote:<br>
<br>
> When the front-facing proxy receives a message on URL at<br>
</div>><a href="http://idp.example.edu" target="_blank">idp.example.edu</a> <<a href="http://idp.example.edu" target="_blank">http://idp.example.edu</a>> (SSL Certificate) it rewrites<br>
<div>>the URL to communicate with the back-end Shibboleth server to<br>
</div>><a href="http://shib.example.edu" target="_blank">shib.example.edu</a> <<a href="http://shib.example.edu" target="_blank">http://shib.example.edu</a>>. This breaks the SAML<br>
<div>>implementation which (like you said) requires that the URL that receives<br>
>the message also matches the SAML EndPoint Location.<br>
<br>
</div>Then your web server isn't configured properly and you just need to fix<br>
it. You need to virtualize it to issue redirects and compute URLs as<br>
<a href="http://idp.example.edu" target="_blank">idp.example.edu</a>. That's standard.<br>
<div><br>
> The original question is whether or not there is a way<br>
> of managing this problem via SAML configuration, a hack or something<br>
>more elegant.<br>
<br>
</div>The latter. Standard host virtualization.<br>
<div><div><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>