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
<[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
