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.
<%
}
%>
<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
