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
>> <lrozenbl...@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
>>>>>>> <lrozenbl...@gmail.com> wrote:
>>>>>>>> I think I could reproduce my problem also on experimenting with your
>>>>>>>> examples!
>>>>>>>>
>>>>>>>> I went exactly by your steps but my JSP is an extended version of
>>>>>>>> yours ( I add it to attachment )
>>>>>>>>
>>>>>>>> In the ROOT/test.jsp I added code to set a session attribute if the
>>>>>>>> user principal is not null.
>>>>>>>> I expect that after logging out via another application (using SSO) my
>>>>>>>> session attribute won't be there (my expectation of SingleSignOff is
>>>>>>>> complete session invalidation).
>>>>>>>>
>>>>>>>> However it's not the case : after logging out in security/protected
>>>>>>>> the session attribute is still kept (while UserPrincipal is null).
>>>>>>>>
>>>>>>>>
>>>>>>>> Complete scenario:
>>>>>>>>
>>>>>>>> - request ROOT/test.jsp
>>>>>>>> - no authenticated user
>>>>>>>> - no marker attribute in session
>>>>>>>>
>>>>>>>> - request examples/jsp/security/protected
>>>>>>>> - FORM login prompt, login, see index.jsp
>>>>>>>>
>>>>>>>> - request ROOT/test.jsp
>>>>>>>> - shows user authenticated above. SSO cookie has a path of / so gets
>>>>>>>> returned with all requests. This exposes the UserPrincipal to all
>>>>>>>> apps
>>>>>>>> - marker attribute is shown from session.
>>>>>>>>
>>>>>>>> - request examples/jsp/security/protected
>>>>>>>> - see index.jsp
>>>>>>>> - click logout
>>>>>>>> - see FORM login page
>>>>>>>>
>>>>>>>> - request ROOT/test.jsp
>>>>>>>> - no authenticated user. As expected. Logout above has destroyed SSO
>>>>>>>> session and removed SSO cookie
>>>>>>>>
>>>>>>>> However - the marker attribute is STILL in session of ROOT
>>>>>>>> webapplication.
>>>>>>>> For us it means that the session is NOT invalidated correctly.
>>>>>>>>
>>>>>>>> Thanks for your feedback and detail scenario you sent, I think it
>>>>>>>> helped discover a probable bug...
>>>>>>>>
>>>>>>>> On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum
>>>>>>>> <lrozenbl...@gmail.com> wrote:
>>>>>>>>> Hello!
>>>>>>>>> I tried 8.0.17 (previously I had 8.0.15) and we still have the same
>>>>>>>>> problem with same possible workaround.
>>>>>>>>>
>>>>>>>>> I'll go through your examples, try them and compare what's the
>>>>>>>>> difference.
>>>>>>>>>
>>>>>>>>> On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas <ma...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>> On 20/01/2015 08:10, Leonid Rozenblyum wrote:
>>>>>>>>>>> Thank you, Mark!
>>>>>>>>>>
>>>>>>>>>> I spent some time stepping through the code using a default Tomcat
>>>>>>>>>> install with the following changes:
>>>>>>>>>> - SSO Valve uncommented in server.xml
>>>>>>>>>> - test.jsp added to ROOT app that shows request.getUserPrincipal
>>>>>>>>>> - uncomment user definitions in tomcat-users.xml
>>>>>>>>>>
>>>>>>>>>> Note that the examples app ships with a protected page that requires
>>>>>>>>>> authentication.
>>>>>>>>>>
>>>>>>>>>> I see the following:
>>>>>>>>>>
>>>>>>>>>> - request ROOT/test.jsp
>>>>>>>>>> - no authenticated user
>>>>>>>>>>
>>>>>>>>>> - request examples/jsp/security/protected
>>>>>>>>>> - FORM login prompt, login, see index.jsp
>>>>>>>>>>
>>>>>>>>>> - request ROOT/test.jsp
>>>>>>>>>> - shows user authenticated above. SSO cookie has a path of / so
>>>>>>>>>> gets
>>>>>>>>>> returned with all requests. This exposes the UserPrincipal to all
>>>>>>>>>> apps
>>>>>>>>>>
>>>>>>>>>> - request examples/jsp/security/protected
>>>>>>>>>> - see index.jsp
>>>>>>>>>> - click logout
>>>>>>>>>> - see FORM login page
>>>>>>>>>>
>>>>>>>>>> - request ROOT/test.jsp
>>>>>>>>>> - no authenticated user. As expected. Logout above has destroyed
>>>>>>>>>> SSO
>>>>>>>>>> session and removed SSO cookie
>>>>>>>>>>
>>>>>>>>>> So, in short, I am seeing the behaviour you expect to see. I'm doing
>>>>>>>>>> this with 9.0.x (trunk) but that should be the same as the latest
>>>>>>>>>> 80.x
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> A couple of things to check:
>>>>>>>>>> - are you using the latest 8.0.x release (8.0.17 - I need to send out
>>>>>>>>>> the announcement)
>>>>>>>>>> - Turn on debug logging for the Host where you added the SSO valve -
>>>>>>>>>> you
>>>>>>>>>> should see debug messages from the SSO valve which will show when
>>>>>>>>>> sessions get created, destroyed etc.
>>>>>>>>>>
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas <ma...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On 16/01/2015 14:05, Leonid Rozenblyum wrote:
>>>>>>>>>>>>> Hello Mark.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We do explicit forced expiration of http session in one of SSO
>>>>>>>>>>>>> enabled
>>>>>>>>>>>>> apps (Application1 : session.invalidate() )
>>>>>>>>>>>>> and it didn't cause session expiration in other Apps
>>>>>>>>>>>>>
>>>>>>>>>>>>> (only workaround with adding security-constraint to other apps
>>>>>>>>>>>>> that I
>>>>>>>>>>>>> mentioned above helped).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomcat version is 8.0.15. OS tested was both linux & windows
>>>>>>>>>>>>>
>>>>>>>>>>>>> Probably I need to prepare minimal test case since it looks like
>>>>>>>>>>>>> a bug, right?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes to the possible bug. Thanks but no need at this point for the
>>>>>>>>>>>> test
>>>>>>>>>>>> case. I'll take a look at what is going on.
>>>>>>>>>>>>
>>>>>>>>>>>> Mark
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Jan 16, 2015 at 2:53 PM, Mark Thomas <ma...@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> On 15/01/2015 15:46, Leonid Rozenblyum wrote:
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have > 2 web-applications which are running on the same host.
>>>>>>>>>>>>>>> The Valve SingleSignOn is enabled.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Application1 has security-constraint and login-config elements
>>>>>>>>>>>>>>> in web.xml
>>>>>>>>>>>>>>> Application2, 3 etc has no such definitions
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Technically Application1 is acting as a security gate. All other
>>>>>>>>>>>>>>> applications are redirected to it if userPrincipal is not found.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In this scenario Single Sign ON works fine - after
>>>>>>>>>>>>>>> authenticating in
>>>>>>>>>>>>>>> Application1, all other applications have correction
>>>>>>>>>>>>>>> userPrincipal.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However Single Sign OFF doesn't work in this configuration. If I
>>>>>>>>>>>>>>> logout in App1, other sessions are not invalidated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How can this be overcomed? Is it a bug or works-as-intended?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Explicit, forced expiration of the HTTP session in any SSO
>>>>>>>>>>>>>> enabled web
>>>>>>>>>>>>>> application should destroy the SSO session and in turn trigger
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> expiration of the HTTP session for every other SSO enabled web
>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Session expiration due to timeout in an SSO enabled web
>>>>>>>>>>>>>> application only
>>>>>>>>>>>>>> terminates the HTTP session for that web application. The SSO
>>>>>>>>>>>>>> session is
>>>>>>>>>>>>>> unaffected (unless this was the last HTTP session associated
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> SSO session in which case the SSO session is removed).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mark
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
