I think I could reproduce my problem also on experimenting with your examples!
I went exactly by your steps but my JSP is an extended version of yours ( I add it to attachment ) In the ROOT/test.jsp I added code to set a session attribute if the user principal is not null. I expect that after logging out via another application (using SSO) my session attribute won't be there (my expectation of SingleSignOff is complete session invalidation). However it's not the case : after logging out in security/protected the session attribute is still kept (while UserPrincipal is null). Complete scenario: - request ROOT/test.jsp - no authenticated user - no marker attribute in session - request examples/jsp/security/protected - FORM login prompt, login, see index.jsp - request ROOT/test.jsp - shows user authenticated above. SSO cookie has a path of / so gets returned with all requests. This exposes the UserPrincipal to all apps - marker attribute is shown from session. - request examples/jsp/security/protected - see index.jsp - click logout - see FORM login page - request ROOT/test.jsp - no authenticated user. As expected. Logout above has destroyed SSO session and removed SSO cookie However - the marker attribute is STILL in session of ROOT webapplication. For us it means that the session is NOT invalidated correctly. Thanks for your feedback and detail scenario you sent, I think it helped discover a probable bug... On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum <lrozenbl...@gmail.com> wrote: > Hello! > I tried 8.0.17 (previously I had 8.0.15) and we still have the same > problem with same possible workaround. > > I'll go through your examples, try them and compare what's the difference. > > On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas <ma...@apache.org> wrote: >> On 20/01/2015 08:10, Leonid Rozenblyum wrote: >>> Thank you, Mark! >> >> I spent some time stepping through the code using a default Tomcat >> install with the following changes: >> - SSO Valve uncommented in server.xml >> - test.jsp added to ROOT app that shows request.getUserPrincipal >> - uncomment user definitions in tomcat-users.xml >> >> Note that the examples app ships with a protected page that requires >> authentication. >> >> I see the following: >> >> - request ROOT/test.jsp >> - no authenticated user >> >> - request examples/jsp/security/protected >> - FORM login prompt, login, see index.jsp >> >> - request ROOT/test.jsp >> - shows user authenticated above. SSO cookie has a path of / so gets >> returned with all requests. This exposes the UserPrincipal to all >> apps >> >> - request examples/jsp/security/protected >> - see index.jsp >> - click logout >> - see FORM login page >> >> - request ROOT/test.jsp >> - no authenticated user. As expected. Logout above has destroyed SSO >> session and removed SSO cookie >> >> So, in short, I am seeing the behaviour you expect to see. I'm doing >> this with 9.0.x (trunk) but that should be the same as the latest 80.x >> release. >> >> A couple of things to check: >> - are you using the latest 8.0.x release (8.0.17 - I need to send out >> the announcement) >> - Turn on debug logging for the Host where you added the SSO valve - you >> should see debug messages from the SSO valve which will show when >> sessions get created, destroyed etc. >> >> Mark >> >> >>> >>> On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas <ma...@apache.org> wrote: >>>> On 16/01/2015 14:05, Leonid Rozenblyum wrote: >>>>> 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? >>>> >>>> Yes to the possible bug. Thanks but no need at this point for the test >>>> case. I'll take a look at what is going on. >>>> >>>> Mark >>>> >>>> >>>>> >>>>> >>>>> 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 >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >> >> >> --------------------------------------------------------------------- >> 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