tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pottinger, Hardy J." <Pottinge...@missouri.edu>
Subject RE: seeking help with stabilizing the persistence of a JSESSIONID
Date Fri, 02 Oct 2015 21:42:25 GMT
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 [chris@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
> [chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message