mysteriously expiring sessions

[Pottinger, Hardy J.]

Thanks, Scott, this message was a nice gentle reminder to look at our application logs... which we have looked at in the past, but not in as great detail as we did for this event. Upon doing so, we found evidence of a timeout... it wasn't a Shibboleth session timeout, but a Tomcat session. Turns out the one dial we have not yet tried to turn is the default Tomcat session timeout, which is 30 minutes. Turning that dial now.

--Hardy
________________________________________
From: users [users-bounces at shibboleth.net] on behalf of Cantor, Scott [cantor.2 at osu.edu]
Sent: Thursday, February 04, 2016 6:10 PM
To: Shib Users
Subject: RE: mysteriously expiring sessions

> Has anyone else observed Shibboleth incorrectly expiring session
> information from the cache? Is there any configuration option I should be
> looking at that would prevent this from happening? Thanks!

People report that all the time. Not one documented instance has ever been identified with proof.

Usually the session is invalidated and something in native.log mentions it happening. Address changing, that sort of thing. Also common with vendor IdPs to see SessionNotOnOrAfter set to a crazy value up front, and the SP enforces that as an upper bound.

Note that the expiration of the records in the cache is timeout driven, not lifetime driven. Accessing the session slides up the expiration by the timeout limit so that the record disappears if the timeout is reached. Lifetime limits are checked on every access.

Note also that there are many interacting settings in the SP alone, like the SessionCache's own policies, not to mention the application layer sorts of things that go on.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net