Hi, Chris, sorry for letting this thread drop for so long, I was directed to focus elsewhere for a while, but I'm back on this again. I've been comparing authentication methods of DSpace--our simple password AuthN and our Shibboleth AuthN methods--to see what might be the difference on how the session is treated. The one thing that jumps out at me is that our password AuthN code is all internal to DSpace, and Tomcat is never involved in that authentication scheme, it's only ever used for providing the session ID. It looks like our Shibboleth authentication code similarly utilizes Tomcat for the session ID, however, the session responsibility is more complicationed. It goes like this:
DSpace -> Shibboleth IdP -> DSpace So, my theory is that somehow Tomcat is being made aware of the authentication state (thus triggering Session Fixation Prevention). Nothing in our code ever informs Tomcat of the authentication state of the session. So, it has to be something in the Apache HTTPD, or Shibboleth configuration that is telling Tomcat that an authentication has occurred. I was thinking this might have been due to the AJP connector attribute: tomcatAuthentication [1], however, setting this to false has had no impact on the behavior of our application. Perhaps I should be looking at the mod_proxy_ajp configuration in HTTPD. Anyway, I figured you deserved a progress report, and there it is. --Hardy [1] https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html ________________________________________ From: Christopher Schultz [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 4:15 PM To: Tomcat Users List Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hardy, On 9/10/15 5:08 PM, Pottinger, Hardy J. wrote: > I can see in our log files that we log the session ID as part of > the authentication process.... so it's probable that our > authentication code needs a bit more work to accommodate the > changing session ID. I'll see if I can figure it out. If you store the session id somewhere instead of always going-back to the actual session object to grab its id, you may have a problem. I believe there is a (non-spec-standard) listener you can attach that will be notified when sessions change ids. - -chris > ________________________________________ From: Christopher Schultz > [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 > 2:57 PM To: Tomcat Users List Subject: Re: seeking help with > stabilizing the persistence of a JSESSIONID > > Hardy, > > On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote: >>> putting Serializable objects in the session is surely a good >>> idea in general. > >> I agree, especially, as you mention, if we intend to distribute >> sessions among various containers. > >>> Tomcat's session-fixation-prevention amounts to changing the >>> session identifier while keeping the session in-tact. So >>> unless you are using distributable sessions, this is unlikely >>> to be the problem. > >> You're absolutely right. I now have a serialized attribute, >> which is still lost upon the creation of the new session. Is >> there anything similar I can try, to ensure that the session >> attributes from the previous session are faithfully copied to the >> new session, after session-fixation-prevention does its thing? > > It's simpler than you think. Tomcat really does nothing other than > this after successful authentication: > > session.setSessionId(randomNewSessionId); > > The "new" session is in fact the same as the old session -- it > just has a new identifier. The client will get a Set-Cookie > response changing the JSESSIONID cookie value, and any URLs encoded > with HttpServletResponse.encodeURL or > HttpServletResponse.encodeRedirectURL will include the updated > session identifier (if appropriate). > > So the "loss" of your session attribute is puzzling. You could > write a noisy HttpSessionAttributeListener that logs every > session-attribute event (with a stack trace) to see if that > attribute is being removed elsewhere. > > -chris > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8fLsAAoJEBzwKT+lPKRYWDAP/jjiOE3HurXXYMKfy02+kONx ao4Bz7ne/zQX7lXBgBuI+lF4MS78oXWx2rp5nF3H/VPXAZ2JesgfwU+U+VbagU8m 7PjCBQaY4QyceyJg7PkSdAT130xif/9sdlmml+qDBSRogBb8cO7TLxxPQZeL808I +1FL5KnAb5JK3jIwYkYY0/IH/r2zaMYeawHofyP+uDLvGQmz3fCJfTq5T0IZYAcy P2tiId0dVxmlF70mcP71SVeHNowBKkNucNCnubM1rNPxCc84zgbvc6mYw6jf2Daq 5MlRyCLrjFaTlEHkLkIjlbLHav5CXFkom7jvBlg1jv852Wzjf3RKmzCzzPOSAsvd GCxi54wU9j0LDFwxBvyro14j56eBlaPcT//7VrZDrL8/HHv37PvivYZ0Iw8dTTls kNKPzFHg0FVYj3kq8DDof3H1YJ+LV8LalRYS/qqv/LAxzq9lSe5qObovd8MoVuPz /IePfZLkNV9cLVZo/iIuvfrpKY41gdGD1hrlY9+F6BPhPHoNpCj5n1r7UK9F38gr qXP5IdrpN7uSnMGpzvbXYSwrRswBTyQVShqsdCVJQWS++GLjLDWxdv/fxbYXc9ac oMyeEoCpinzJ+MmTMIc9dAJecGUDayJP+KMQvabPUkd4Ee33R+27P9/zoQI12Sds 4uCO7ksTV7qLWpjybm3o =n+Ja -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
