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
