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
