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
