tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: SingleSignonValve and webapp session timeout
Date Tue, 11 Oct 2011 16:35:45 GMT
On 11/10/11 16:27, Christopher Schultz wrote:

Thanks very much for your speedy and informative reply, Christopher.

While my question is fresh in your mind, I hope you will not mind too 
much if I ask a couple of relevant questions to clarify your answers below.

> Hash: SHA1
> Brian,
> On 10/11/2011 10:09 AM, Brian Burch wrote:
>> 6. The user tries to refresh the second webapp's page after about
>> 25 minutes, but the GET fails with 403 status and the explanation
>> "access to resource has been denied". Apparently, the user's
>> session has been timed out and so he or she is no longer authorised
>> to access the resource.
> This sounds like expected behavior to me: sessions are distinct
> between webapps, even when SSO is being used. That means that the
> user's session in the "static" webapp will expire 20 minutes after
> their last request to "static", regardless of activity in other
> webapps. When that session times-out, the requirements of SSO are that
> all webapps participating in the SSO session are terminated.
>> These observations suggest the session is being timed out based on
>> the value for the webapp first encountered by SSO, possibly
>> associated with the entire SSO Realm, and is not being modified by
>> the individual webapps within the Realm.
> I think the thing you're missing is that it's not a single session,
> it's a single sign-on. The sessions themselves are distinct.

OK, I think I understand the distinction you are making, which is 
consistent with there being a Session array (rather than a simple field) 
in the SingleSignOnEntry class.

But I am having trouble understanding the life cycle of a Session. If 
the browser has navigated away from my "static" webapp container, into a 
completely different webapp container, why does it still have an 
associated Session? I can understand how the browser would retain two 
Sessions if it held two tabs open, one to each webapp. I guess in my 
situation (not everyone's), my "static" webapp is the only thing that 
knows anything about the state of the browser, so the Host and/or Valve 
don't know whether the browser/user will ever interact with my "static" 
webapp again and so feel obliged to keep the Session alive "just in case".

I suppose what I really need is two levels of timeout logic:
a) each individual webapp already has its own session-timeout defined 
within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL 
Session should be invalidated.
b) SSO should only invalidate the "single sign-on" instance/entry when 
THE FINAL webapp Session is expired or otherwise invalidated (and the 
Session array is empty).

Is it possible for my menu.jsp to invalidate its own Session, without 
logging the user off, when it knows the browser will be sending on a 
one-way trip to another webapp? My feeling is "no" because that would 
leave the SSO instance without any active Sessions until the new webapp 
starts serving the client.

Do I need to start researching LifeCycleListeners to achieve my 
objective, or would that be a pointless approach?

>> Regardless of my open question, **something** has been waiting for
>> a timer to pop. The timer must have been set to 20 minutes at the
>> time it was scheduled, and the session has already been timed-out.
>> I can see that a SingleSignOnEntry cache entry has an array to
>> carry multiple Session instances. I wonder whether the "wrong"
>> Session instance (i.e. not the one currently in conversation with
>> the client) has been used to establish the timer?
>> I have read the explanation for the
>> org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it
>> doesn't really make a lot of sense to me and I'm not sure whether
>> it is relevant to my problem.
> I don't believe it's relevant.
>> Does my description make sense? I'm not sure whether I am looking
>> at a bug, or simply a case of how it is intended to work. Does
>> anyone have any helpful suggestions about how to achieve my desired
>> behaviour?
> I think you have two options:
> 1. Configure your session timeouts differently
> 2. Have each webapp ping the others periodically, or whenever a
>     request comes in for a particular session
> The difficult part about #1 is that a user could use a webapp for 4
> hours and that's an unreasonable timeout for a session. You could wait
> for authentication, then increase the timeout, but you still have the
> same problem for legitimate users.
> #2 requires that you have webapps communicate with each other and
> masquerade as the user in question. There may be performance and
> security issues that you'll want to sort-out before you decide to do
> this kind of thing.
> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> s30An1lMjyuEkth0R97atkiyGm1JNALe
> =9m7N
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message