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
