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
