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!
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
