tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Drzewiecki" <>
Subject Re: Standart Sessions included in the SSO Session expire
Date Wed, 03 Aug 2005 12:58:55 GMT
Remy Maucherat <> wrote:
> Dominik Drzewiecki wrote:
>> I have a conceptual question wrt the Single Sign On behaviour.
>> Let's assume there are two applications /app1 and /app2, and there is 
>> a SSO 
>> setup on them both. Now, user logs into the /app1 (which requires 
>> authentication) and /app2 (which uses SSO Cookie, no authentication 
>> then), 
>> and later on makes use of only one of them (say: /app1) for quite a 
>> long 
>> time, so that this period outlives the session expiry date of the 
>> unused 
>> application (/app2). Provided that both applications establish their 
>> own 
>> sessions the one created in the scope of constantly used application 
>> (/app1) wouldn't expire, while the second one definitely would. 
>> Now the question: As both sessions are gathered into a higher-level 
>> SSO 
>> session, would it be against the specification if *all* standard 
>> sessions 
>> were aged (eg. by calling session.access()) on each request containing 
>> valid SSO cookie? I suggest that there should be a flag on the SSO 
>> Valve, 
>> that is org.apache.catalina.authenticator.SingleSignOn allowing users 
>> to 
>> specify the behaviour. If nobody objects, I could try to provide 
>> apropriate 
>> patch.
> The purpose of single sign on is to deal with authentication issues, not 
> modify session lifecycle. Overall, you really need to design your web 
> applications as if they were independent.
The applications are indeed independant. However the current implementation 
of the SingleSignOn valve *does* modify the session - whenever user logs 
out of one of the apps (I assume this means the invocation od 
session.invalidate()) the rest of the sessions gathered under the same 
SSOid get destroyed too. I just wanted to say that if we destroy sessions 
of the other applications, we should also keep-them-alive, for the sake of 
consistency. Just my $.02

> Of course, it is fine to implement your own custom behavior should you 
> need it.
Of course, I know it ;) I was just wondering if a fix/enhancement to the 
current behaviour might be required/welcome.


PS. Sorry for posting twice, damn webmail client ;)

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

View raw message