You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Leonid Rozenblyum <lr...@gmail.com> on 2015/01/15 16:46:04 UTC
[ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
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?
(our current possible workaround could be specifying
security-constraint also in App2, App3 but we have rather a big bunch
of them and it looks like rather complex configuration propagation
which should be not forgotten when new webapps are added).
Thanks for any help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
I wonder if it's possible in HttpSessionListener implementation get
access to actual Tomcat's StandardSession?
HttpSessionEvent contains reference to StandardSessionFacade.
Otherwise I cannot access Manager, Context etc which should led me to
SingleSignOn.
Should I go through dangerous reflection ways or there are some
'recommended' ways to access the internals?
Thanks.
On Thu, Jan 29, 2015 at 1:25 PM, Leonid Rozenblyum
<lr...@gmail.com> wrote:
> Thanks for the great advice!
>
> On Thu, Jan 29, 2015 at 12:57 PM, Mark Thomas <ma...@apache.org> wrote:
>> On 29/01/2015 10:54, Leonid Rozenblyum wrote:
>>> Hello! I'm trying to extend the SingleSignOn valve and if possible
>>> could you point me how can I create a global session listener
>>> without modifying configurations of web applications?
>>>
>>> The idea is that I should catch all 'session create' events from all
>>> webapps, and if they have the 'custom SSO valve' as parent - add them
>>> to SSO irregardless the fact the have no authentication themselves.
>>>
>>> Thanks for any help!
>>
>> Put your listener in conf/web.xml. That file is applied to all web
>> applications.
>>
>> Mark
>>
>>
>>>
>>> On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
>>> <lr...@gmail.com> wrote:
>>>> Hello Mark!
>>>>
>>>> I'll investigate deeper the SingleSignOn class to understand how to
>>>> extend it to allow adding the session always.
>>>>
>>>>
>>>> To summarize : my understanding of current behaviour is following:
>>>>
>>>> - if a web application uses authentication (has security-constraint?)
>>>> -> then SingleSignOn will provide :
>>>> a) correct request.getUserPrincipal()
>>>> b) correct session invalidation
>>>>
>>>> - if a web application is not using authentication -> SingleSignOn
>>>> will just provide
>>>> a) correct request.getUserPrincipal()
>>>>
>>>> Probably there were some logical architectural backgrounds to take
>>>> this decision
>>>>
>>>> But for us it was counter-intuitive. We expected either a)+b) are both
>>>> available or nothing.
>>>>
>>>> Presence of just a) caused unexpected security issues in our app when
>>>> after logout and logging in with lower permissions user had access to
>>>> data stored for high-privileged user.
>>>>
>>>> Thanks for your help!
>>>>
>>>> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>> 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
>>>>>>>> <lr...@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
>>>>>>>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
Thanks for the great advice!
On Thu, Jan 29, 2015 at 12:57 PM, Mark Thomas <ma...@apache.org> wrote:
> On 29/01/2015 10:54, Leonid Rozenblyum wrote:
>> Hello! I'm trying to extend the SingleSignOn valve and if possible
>> could you point me how can I create a global session listener
>> without modifying configurations of web applications?
>>
>> The idea is that I should catch all 'session create' events from all
>> webapps, and if they have the 'custom SSO valve' as parent - add them
>> to SSO irregardless the fact the have no authentication themselves.
>>
>> Thanks for any help!
>
> Put your listener in conf/web.xml. That file is applied to all web
> applications.
>
> Mark
>
>
>>
>> On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
>> <lr...@gmail.com> wrote:
>>> Hello Mark!
>>>
>>> I'll investigate deeper the SingleSignOn class to understand how to
>>> extend it to allow adding the session always.
>>>
>>>
>>> To summarize : my understanding of current behaviour is following:
>>>
>>> - if a web application uses authentication (has security-constraint?)
>>> -> then SingleSignOn will provide :
>>> a) correct request.getUserPrincipal()
>>> b) correct session invalidation
>>>
>>> - if a web application is not using authentication -> SingleSignOn
>>> will just provide
>>> a) correct request.getUserPrincipal()
>>>
>>> Probably there were some logical architectural backgrounds to take
>>> this decision
>>>
>>> But for us it was counter-intuitive. We expected either a)+b) are both
>>> available or nothing.
>>>
>>> Presence of just a) caused unexpected security issues in our app when
>>> after logout and logging in with lower permissions user had access to
>>> data stored for high-privileged user.
>>>
>>> Thanks for your help!
>>>
>>> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas <ma...@apache.org> wrote:
>>>> 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
>>>>>>> <lr...@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
>>>>>>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Mark Thomas <ma...@apache.org>.
On 29/01/2015 10:54, Leonid Rozenblyum wrote:
> Hello! I'm trying to extend the SingleSignOn valve and if possible
> could you point me how can I create a global session listener
> without modifying configurations of web applications?
>
> The idea is that I should catch all 'session create' events from all
> webapps, and if they have the 'custom SSO valve' as parent - add them
> to SSO irregardless the fact the have no authentication themselves.
>
> Thanks for any help!
Put your listener in conf/web.xml. That file is applied to all web
applications.
Mark
>
> On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
> <lr...@gmail.com> wrote:
>> Hello Mark!
>>
>> I'll investigate deeper the SingleSignOn class to understand how to
>> extend it to allow adding the session always.
>>
>>
>> To summarize : my understanding of current behaviour is following:
>>
>> - if a web application uses authentication (has security-constraint?)
>> -> then SingleSignOn will provide :
>> a) correct request.getUserPrincipal()
>> b) correct session invalidation
>>
>> - if a web application is not using authentication -> SingleSignOn
>> will just provide
>> a) correct request.getUserPrincipal()
>>
>> Probably there were some logical architectural backgrounds to take
>> this decision
>>
>> But for us it was counter-intuitive. We expected either a)+b) are both
>> available or nothing.
>>
>> Presence of just a) caused unexpected security issues in our app when
>> after logout and logging in with lower permissions user had access to
>> data stored for high-privileged user.
>>
>> Thanks for your help!
>>
>> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas <ma...@apache.org> wrote:
>>> 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
>>>>>> <lr...@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
>>>>>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
Hello! I'm trying to extend the SingleSignOn valve and if possible
could you point me how can I create a global session listener
without modifying configurations of web applications?
The idea is that I should catch all 'session create' events from all
webapps, and if they have the 'custom SSO valve' as parent - add them
to SSO irregardless the fact the have no authentication themselves.
Thanks for any help!
On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
<lr...@gmail.com> wrote:
> Hello Mark!
>
> I'll investigate deeper the SingleSignOn class to understand how to
> extend it to allow adding the session always.
>
>
> To summarize : my understanding of current behaviour is following:
>
> - if a web application uses authentication (has security-constraint?)
> -> then SingleSignOn will provide :
> a) correct request.getUserPrincipal()
> b) correct session invalidation
>
> - if a web application is not using authentication -> SingleSignOn
> will just provide
> a) correct request.getUserPrincipal()
>
> Probably there were some logical architectural backgrounds to take
> this decision
>
> But for us it was counter-intuitive. We expected either a)+b) are both
> available or nothing.
>
> Presence of just a) caused unexpected security issues in our app when
> after logout and logging in with lower permissions user had access to
> data stored for high-privileged user.
>
> Thanks for your help!
>
> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas <ma...@apache.org> wrote:
>> 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
>>>>> <lr...@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
>>>>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
Hello Mark!
I'll investigate deeper the SingleSignOn class to understand how to
extend it to allow adding the session always.
To summarize : my understanding of current behaviour is following:
- if a web application uses authentication (has security-constraint?)
-> then SingleSignOn will provide :
a) correct request.getUserPrincipal()
b) correct session invalidation
- if a web application is not using authentication -> SingleSignOn
will just provide
a) correct request.getUserPrincipal()
Probably there were some logical architectural backgrounds to take
this decision
But for us it was counter-intuitive. We expected either a)+b) are both
available or nothing.
Presence of just a) caused unexpected security issues in our app when
after logout and logging in with lower permissions user had access to
data stored for high-privileged user.
Thanks for your help!
On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas <ma...@apache.org> wrote:
> 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
>>>> <lr...@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
>>>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Mark Thomas <ma...@apache.org>.
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
>>> <lr...@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
>>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
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).
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
>> <lr...@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
>>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Mark Thomas <ma...@apache.org>.
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
> <lr...@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
>> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
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
<lr...@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
> <lr...@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-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
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
<lr...@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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
Thank you, 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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Leonid Rozenblyum <lr...@gmail.com>.
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?
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org