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
