Hello Mark. We do explicit forced expiration of http session in one of SSO enabled apps (Application1 : session.invalidate() ) and it didn't cause session expiration in other Apps
(only workaround with adding security-constraint to other apps that I mentioned above helped). Tomcat version is 8.0.15. OS tested was both linux & windows Probably I need to prepare minimal test case since it looks like a bug, right? On Fri, Jan 16, 2015 at 2:53 PM, Mark Thomas <ma...@apache.org> wrote: > On 15/01/2015 15:46, Leonid Rozenblyum wrote: >> Hello. >> >> I have > 2 web-applications which are running on the same host. >> The Valve SingleSignOn is enabled. >> >> Application1 has security-constraint and login-config elements in web.xml >> Application2, 3 etc has no such definitions >> >> Technically Application1 is acting as a security gate. All other >> applications are redirected to it if userPrincipal is not found. >> >> In this scenario Single Sign ON works fine - after authenticating in >> Application1, all other applications have correction userPrincipal. >> >> However Single Sign OFF doesn't work in this configuration. If I >> logout in App1, other sessions are not invalidated. >> >> How can this be overcomed? Is it a bug or works-as-intended? > > Explicit, forced expiration of the HTTP session in any SSO enabled web > application should destroy the SSO session and in turn trigger the > expiration of the HTTP session for every other SSO enabled web application. > > Session expiration due to timeout in an SSO enabled web application only > terminates the HTTP session for that web application. The SSO session is > unaffected (unless this was the last HTTP session associated with the > SSO session in which case the SSO session is removed). > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org