I wonder if it's possible in HttpSessionListener implementation get
access to actual Tomcat's StandardSession?
HttpSessionEvent contains reference to StandardSessionFacade.
Otherwise I cannot access Manager, Context etc which should led me to
SingleSignOn.
Should I go through dangerous reflection ways or there are some
'recommended' ways to access the internals?
Thanks.
On Thu, Jan 29, 2015 at 1:25 PM, Leonid Rozenblyum
<lrozenbl...@gmail.com> wrote:
> Thanks for the great advice!
>
> On Thu, Jan 29, 2015 at 12:57 PM, Mark Thomas <ma...@apache.org> wrote:
>> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
