On 29/01/2015 10:54, Leonid Rozenblyum wrote: > Hello! I'm trying to extend the SingleSignOn valve and if possible > could you point me how can I create a global session listener > without modifying configurations of web applications? > > The idea is that I should catch all 'session create' events from all > webapps, and if they have the 'custom SSO valve' as parent - add them > to SSO irregardless the fact the have no authentication themselves. > > Thanks for any help!
Put your listener in conf/web.xml. That file is applied to all web applications. Mark > > On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum > <lrozenbl...@gmail.com> wrote: >> Hello Mark! >> >> I'll investigate deeper the SingleSignOn class to understand how to >> extend it to allow adding the session always. >> >> >> To summarize : my understanding of current behaviour is following: >> >> - if a web application uses authentication (has security-constraint?) >> -> then SingleSignOn will provide : >> a) correct request.getUserPrincipal() >> b) correct session invalidation >> >> - if a web application is not using authentication -> SingleSignOn >> will just provide >> a) correct request.getUserPrincipal() >> >> Probably there were some logical architectural backgrounds to take >> this decision >> >> But for us it was counter-intuitive. We expected either a)+b) are both >> available or nothing. >> >> Presence of just a) caused unexpected security issues in our app when >> after logout and logging in with lower permissions user had access to >> data stored for high-privileged user. >> >> Thanks for your help! >> >> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas <ma...@apache.org> wrote: >>> On 22/01/2015 16:25, Leonid Rozenblyum wrote: >>>> So doesn't "As soon as the user logs out of one web application (for >>>> example, by invalidating the corresponding session if form based login >>>> is used), the user's sessions in all web applications will be >>>> invalidated. " ( this phrase is from official doc) imply that all >>>> sessions are invalidated and thus attributes are cleared? >>>> >>>> (and as I mentioned above : there is some workaround that looks like >>>> forces Tomcat to work exactly like this). >>> >>> A session is only added to SSO if the web application uses >>> authentication. You could extend the SSOValve to always add the session >>> if you wish. >>> >>> Mark >>> >>> >>>> >>>> On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas <ma...@apache.org> wrote: >>>>> On 22/01/2015 16:12, Leonid Rozenblyum wrote: >>>>>> Probably the attachment will be cut out by the mailing server. >>>>>> So I send the text of the test.jsp here: >>>>>> >>>>>> Hello >>>>>> <br /> >>>>>> User Principal: <%= request.getUserPrincipal() %> <br/> >>>>>> >>>>>> <% >>>>>> if (request.getUserPrincipal() != null ) { >>>>>> %> >>>>>> User is authenticated, allow to set session attribute >>>>>> <% >>>>>> request.getSession().setAttribute("markerAttribute", >>>>>> "markerAttributeValue"); >>>>>> } >>>>>> else { >>>>>> %> >>>>>> User is a guest. No setting of any session attributes. >>>>>> <% >>>>>> } >>>>>> %> >>>>> >>>>> You need to remove the session attribute if the user is not >>>>> authentication. >>>>> >>>>> Tomcat's SSO is working as expected. You are, of course, free to >>>>> extend/patch it if you prefer. >>>>> >>>>> Mark >>>>> >>>>>> >>>>>> <br /> >>>>>> >>>>>> Marker Attribute from session: <%= >>>>>> request.getSession().getAttribute("markerAttribute") %> >>>>>> >>>>>> On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum >>>>>> <lrozenbl...@gmail.com> wrote: >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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