<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">13:29:42.783 - DEBUG<br>
[org.eclipse.jetty.rewrite.handler.RuleContainer:167] - rew<br>
rote /cas-server/login to /idp/profile/cas/login<br>
<br>
13:29:43.097 - DEBUG [org.eclipse.jetty.server.Server:520] - RESPONSE<br>
for /cas-s<br>
erver/login h=true<br>
302 null<br>
Set-Cookie: JSESSIONID=qq7wly12bjqbw1rg6ogoltdn;Path=/idp;Secure<br>
Expires: Thu, 01 Jan 1970 00:00:00 GMT<br>
Cache-Control: no-store<br>
Location:<br>
<a href="https://ldap-cgi2.dev.sonoma.edu/portal/index.cgi;jsessionid=qq7wly12bjqbw1rg6ogoltdn?ticket=ST-1454534983074-PNvIpJ7iyd0KrHFy9drsCnoZV" rel="noreferrer" target="_blank">https://ldap-cgi2.dev.sonoma.edu/portal/index.cgi;jsessionid=qq7wly12b<br>
jqbw1rg6ogoltdn?ticket=ST-1454534983074-PNvIpJ7iyd0KrHFy9drsCnoZV</a></blockquote><div><br></div><div>I believe I see what's going on here. First, note that the session ID in the path parameter is the same as that in the Set-Cookie header. Second, this is just "how servlets work," which is something I discovered recently tracking down a similar issue when browser session cookies were turned off. You're effectively getting in the same situation due to cookie path mismatch caused by your rewrite rule. Here's a brief explanation of servlet session mechanics, which I hope will help clarify.</div><div><br></div><div>When a session is started, the servlet container _by default_ sets a path parameter of ;jsessionid=[session ID] at the servlet context path in addition to the Set-Cookie header. If a subsequent request to the IdP contains _both_ the path parameter and the cookie header, the servlet container culls the path parameter since it knows the client has received the cookie. Typically the jsessionid is stripped off naturally during the login process:</div><div><br></div><div><div>GET <a href="https://login.vt.edu/profile/cas/login?service=https://www.middleware.vt.edu/">https://login.vt.edu/profile/cas/login?service=https://www.middleware.vt.edu/</a></div><div>302</div><div>Location:<a href="https://login.vt.edu/profile/cas/login;jsessionid=1mlugzaw2fs9v1enrs7267jnhm?execution=e1s1">https://login.vt.edu/profile/cas/login;jsessionid=1mlugzaw2fs9v1enrs7267jnhm?execution=e1s1</a></div><div>Set-Cookie:JSESSIONID=1mlugzaw2fs9v1enrs7267jnhm;Path=/;Secure</div><div><br></div><div>GET <a href="https://login.vt.edu/profile/cas/login;jsessionid=1mlugzaw2fs9v1enrs7267jnhm?execution=e1s1">https://login.vt.edu/profile/cas/login;jsessionid=1mlugzaw2fs9v1enrs7267jnhm?execution=e1s1</a></div><div>Cookie:JSESSIONID=1mlugzaw2fs9v1enrs7267jnhm</div><div>200</div><div><br></div><div>POST <a href="https://login.vt.edu/profile/cas/login?execution=e1s1">https://login.vt.edu/profile/cas/login?execution=e1s1</a></div><div>302</div><div>Location:<a href="https://login-dev.middleware.vt.edu/profile/cas/login?execution=e1s2">https://login.vt.edu/profile/cas/login?execution=e1s2</a></div></div><div><br></div><div>You can see that the path parameter is gone by the time credentials are posted to the login form. In your case that's not happening presumably because of the mismatch between the session ID cookie path and the location on your IdP.</div><div><br></div><div>The path parameter is appended to every outgoing redirect by the servlet container and happens at such a low level that it's hard to determine when it should be stripped. Here's an issue that I filed when I was fighting this at my home institution:</div><div><br></div><div><a href="https://jira.spring.io/browse/SPR-13693?filter=-2">https://jira.spring.io/browse/SPR-13693?filter=-2</a><br></div><div><br></div><div>You can try getting the cookie path fixed or toggle the Jetty flag I mentioned in the issue above; either should fix you up.</div><div><br></div><div>M<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>