Remy Maucherat <[EMAIL PROTECTED]> 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. cheers, /dd PS. Sorry for posting twice, damn webmail client ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
