<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>Hi Scott, </div>
<div><br>
</div>
<div>I did some tracing with LiveHTTPHeaders and compared between working and non-working servers today. I think I've found the spot where things appear to go off the rails but am not certain what to do about it. We're going to set up a little in-house reverse
proxy and experiment, since it is quite difficult to get the cloud vendor to change settings.</div>
<div><br>
</div>
<div>You said:</div>
<br>
<blockquote type="cite">...The issue isn't what the URLs are<br>
per se, but where/when the session cookie is dropped. That should be<br>
evident from a trace. Once the droppage is confirmed and on what step,<br>
it's a given that there's a mismatch between where it's set and where's<br>
it's not sent back. Then you can figure out which one is off.</blockquote>
<div><br>
</div>
Here's what I have so far. I've boiled down the trace to what I think is most significant:
<div>______________________________</div>
<div>Line 1. <b><a href="https://reverseproxy.com/content">https://reverseproxy.com/content</a></b></div>
<div>
<div>GET /content HTTP/1.1</div>
<div>Host: <a href="http://mlearningqa.med.umich.edu">mlearningqa.med.umich.edu</a></div>
<div><br>
</div>
<div>HTTP/1.1 302 Please Wait</div>
<div>Location: <a href="https://identityprovider.com:8443/nidp/saml2/sso?SAMLRequest=.......*&RelayState=cookie%3">https://identityprovider.com:8443/nidp/saml2/sso?SAMLRequest=.......*&RelayState=cookie%3</a><b>A1409080194_2900</b></div>
</div>
<div>Set-Cookie: _shibstate_<b>1409080194_2900</b>=<b>https%3A%2F%2Freverseproxy.com%2Fcontent%2F</b>; path=/; secure; HttpOnly</div>
<div>Set-Cookie: SABASESSIONID=1336989325.20480.0000; path=/ (this is a non-shibboleth-related cookie set by the Reverse Proxy)</div>
<div>______________________________</div>
<div>Line 23. <b><a href="https://identityprovider.com:8443">https://identityprovider.com:8443</a></b>/nidp/saml2/sso?SAMLRequest=....&RelayState=cookie%3<b>A1409080194_2900</b></div>
<div>GET /nidp/saml2/sso?SAMLRequest=.....&RelayState=cookie%3<b>A1409080194_2900</b> HTTP/1.1</div>
<div>
<div>HTTP/1.1 200 OK</div>
<div>Set-Cookie: JSESSIONID=BC18E99BDCF778DD44FD14B9044953DF; Path=/nidp/; Secure; HttpOnly</div>
<div>Set-Cookie: UrnNovellNidpClusterMemberId=~03~02fdf~1B~16~11uqr; Path=/nidp</div>
<div>Set-Cookie: urn:novell:nidp:cluster:member:id=~03~02fdf~1B~16~11uqr; Path=/nidp</div>
</div>
<div>______________________________</div>
<div>
<div>Line 44. <b>https://</b><b><a href="http://identityprovider.com">identityprovider.com</a></b><b>:8443</b>/nidp/saml2/sso?id=716&sid=0&option=credential&sid=0</div>
<div>POST /nidp/saml2/sso?id=716&sid=0&option=credential&sid=0 HTTP/1.1</div>
<div>Cookie: JSESSIONID=BC18E99BDCF778DD44FD14B9044953DF; UrnNovellNidpClusterMemberId=~03~02fdf~1B~16~11uqr; urn:novell:nidp:cluster:member:id=~03~02fdf~1B~16~11uqr</div>
<div>______________________________</div>
<div>Line 68. <b>https://</b><b><a href="http://identityprovider.com">identityprovider.com</a></b><b>:8443</b>/nidp/saml2/sso?sid=0</div>
<div>POST /nidp/saml2/sso?sid=0 HTTP/1.1</div>
<div>
<div>Cookie: JSESSIONID=BC18E99BDCF778DD44FD14B9044953DF; UrnNovellNidpClusterMemberId=~03~02fdf~1B~16~11uqr; urn:novell:nidp:cluster:member:id=~03~02fdf~1B~16~11uqr</div>
</div>
<div></div>
<div>______________________________</div>
<div>Line 91. <b><a href="https://identityprovider.com">https://identityprovider.com</a></b><b>:8443</b>/nidp/saml2/sso?sid=0</div>
<div>
<div>GET /nidp/saml2/sso?sid=0 HTTP/1.1</div>
<div>Cookie: JSESSIONID=BC18E99BDCF778DD44FD14B9044953DF; UrnNovellNidpClusterMemberId=~03~02fdf~1B~16~11uqr; urn:novell:nidp:cluster:member:id=~03~02fdf~1B~16~11uqr</div>
</div>
<div>______________________________</div>
<div>Line 112. <b><a href="https://reverseproxy.com/content">https://reverseproxy.com/content</a></b>/Shibboleth.sso/SAML2/POST</div>
<div>POST /content/Shibboleth.sso/SAML2/POST HTTP/1.1</div>
<div>Location: <a href="https://identityprovider.com:8443/nidp/saml2/sso?SAMLRequest=...&RelayState=cookie%3">https://identityprovider.com:8443/nidp/saml2/sso?SAMLRequest=...&RelayState=cookie%3</a><b>A1409080201_2348</b></div>
Set-Cookie: _shibstate_<b>1409080201_2348</b>=https%3A%2F%2F<b>reverseproxy.com%2Fcontent%2F%2FShibboleth.sso</b>%2FSAML2%2FPOST; path=/; secure; HttpOnly</div>
<div>______________________________</div>
<div><br>
</div>
<div>Note that a<b> new _shibstate cookie</b> is set at this spot with a new number appended to its name. Its value is now /content//Shibboleth.sso/SAML/POST</div>
<div><br>
</div>
<div>The server that is NOT behind the RP does not do this. Instead it sets a cookie called _shibsession_ at this point and then goes off to the resource that was requested, but this server does not.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>You asked:</div>
<div>
<div>
<blockquote type="cite"><br>
Is there some value this reverse proxy is providing?<br>
</blockquote>
<br>
It is required to enable Javascript communication between frames which would normally be in different domains. This is a requirement of the SCORM standard. With our current in-house hosted LMS, we used virtual directories to get the same result - content in
the same domain as the LMS.</div>
</div>
<div></div>
<div><br>
</div>
<div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>One thing we noticed today in the wiki instructions for Reverse Proxy:</div>
<div>
<ul style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; list-style-type: disc; color: rgb(51, 51, 51); font-family: Arial, sans-serif; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: 11.428571701049805px; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); ">
<li>Note that the path (<code style="font-weight: normal; font-family: monospace; ">/secure</code>) 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
<b>either proxies the resource with the exact same path (<code style="font-family: monospace; ">/secure</code> to <code style="font-family: monospace; ">/secure</code>), or that the proxy is able to rewrite HTTP resonse headers</b> (e.g. the ones containing
the <code style="font-weight: normal; font-family: monospace; ">relayState</code>) before returning results to the client.</li></ul>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy">https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy</a> </div>
<div></div>
<div><br>
</div>
<div>We're mapping <b>/content to / </b> (webroot) So that could be one problem at least.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div> _______________________________________________________________________________</div>
<div><br>
</div>
</div>
<div><br>
On Aug 25, 2014, at 10:19 PM, Cantor, Scott wrote:<br>
<br>
<blockquote type="cite">On 8/25/14, 7:18 PM, "Meiselman, Ellen" <<a href="mailto:emeiselm@med.umich.edu">emeiselm@med.umich.edu</a>> wrote:<br>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">We didn't find any smoking guns until we changed the relayState setting<br>
</blockquote>
<blockquote type="cite">to "cookie" and inspected the value of the cookie. It turns out there is<br>
</blockquote>
<blockquote type="cite">alway a double slash after the "content" part of the path:<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">There are absolutely no trailing slashes after the word "content" in<br>
</blockquote>
<blockquote type="cite">shibboleth2.xml. <br>
</blockquote>
<br>
Well, it's your proxy doing it.<br>
<br>
<blockquote type="cite">A. Do you think the extra slash in path in the cookie value might cause<br>
</blockquote>
<blockquote type="cite">the looping problem?<br>
</blockquote>
<br>
I doubt it, but I guess it's possible. The issue isn't what the URLs are<br>
per se, but where/when the session cookie is dropped. That should be<br>
evident from a trace. Once the droppage is confirmed and on what step,<br>
it's a given that there's a mismatch between where it's set and where's<br>
it's not sent back. Then you can figure out which one is off.<br>
</blockquote>
<br>
<blockquote type="cite"><br>
Is there some value this reverse proxy is providing?<br>
</blockquote>
<br>
It is required to enable Javascript communication between frames which would normally be in different domains. This is a requirement of the SCORM standard. With our current in-house hosted LMS, we used virtual directories to get the same result - content in
the same domain as the LMS.<br>
<br>
In the new cloud system we are attempting to use a reverse proxy to achieve this. While we were looking at the wiki article on Reverse Proxy again today, a member of my team noticed this note: <br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy">https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy</a><br>
<span class="Apple-tab-span" style="white-space:pre"></span>• 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.<br>
<br>
We are not proxying to the identical path. <br>
<br>
https://proxyserver.com/content<br>
<br>
displays content at <br>
<br>
https://contentserver.com<br>
<br>
<br>
<br>
<blockquote type="cite"><br>
-- Scott<br>
<br>
-- <br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br>
</blockquote>
<br>
</div>
<p>**********************************************************<br>
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues </p></body>
</html>