You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Brian Burch <br...@pingtoo.com> on 2011/10/11 16:09:00 UTC
SingleSignonValve and webapp session timeout
I am using tomcat 6.0.28 (actually the 6.0.28-10ubuntu2 package) as a
standalone web server. I am getting timeout behaviour that sort-of makes
sense, but doesn't agree with the way I read the servlet spec.
I have associated the org.apache.catalina.authenticator.SingleSignOn
Valve with my Engine, within the Host definition. It seems to work fine.
1. conf/web.xml sets <session-timeout> to 30 minutes. (I believe this
will be the default used by webapps that do not explicitly define a
value within their individual web.xml files.)
2. My root welcome page does an html redirect to a small webapp called
static, which has its own web.xml. The redirect is to a page which is
protected by a security contraint which requires a FORM-based login
(this server only has an SSL Connector defined). The static web.xml
defines its session-timeout to be 20 minutes.
3. Once the user has authenticated to the static webapp, the client sees
an html page generated by a jsp which provides a menu based on the roles
defined for the individual user.
4. The menu offers url's to other webapps within the same Host and
Realm, therefore within the control of the SSO Valve.
5. When a user navigates to one of these other webapps, it apparently
works fine. However, this second webapp has a web.xml that sets
session-timeout to be 120 minutes.
6. The user tries to refresh the second webapp's page after about 25
minutes, but the GET fails with 403 status and the explanation "access
to resource has been denied". Apparently, the user's session has been
timed out and so he or she is no longer authorised to access the resource.
7. When I attach a debugger to the source code in my second webapp, I
can stop execution and display context variables:
*** HttpServletRequest.StandardSession.maxInactiveInterval has the value
7200 (i.e. 120 minutes),
which is the time defined in the webapp's own xml.
These observations suggest the session is being timed out based on the
value for the webapp first encountered by SSO, possibly associated with
the entire SSO Realm, and is not being modified by the individual
webapps within the Realm.
I can see some relevant logic within the source code of
SingleSignOn.sessionEvent(SessionEvent), but I don't know which session
instance it will be working with:
// Look up the single session id associated with this session (if any)
Session session = event.getSession();
Regardless of my open question, **something** has been waiting for a
timer to pop. The timer must have been set to 20 minutes at the time it
was scheduled, and the session has already been timed-out.
I can see that a SingleSignOnEntry cache entry has an array to carry
multiple Session instances. I wonder whether the "wrong" Session
instance (i.e. not the one currently in conversation with the client)
has been used to establish the timer?
I have read the explanation for the
org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it doesn't
really make a lot of sense to me and I'm not sure whether it is relevant
to my problem.
Does my description make sense? I'm not sure whether I am looking at a
bug, or simply a case of how it is intended to work. Does anyone have
any helpful suggestions about how to achieve my desired behaviour?
(puzzled)
Brian Burch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/11 Brian Burch <br...@pingtoo.com>:
>
> 2. My root welcome page does an html redirect to a small webapp called
> static, which has its own web.xml. The redirect is to a page which is
> protected by a security contraint which requires a FORM-based login (this
> server only has an SSL Connector defined). The static web.xml defines its
> session-timeout to be 20 minutes.
>
>(...)
> 6. The user tries to refresh the second webapp's page after about 25
> minutes, but the GET fails with 403 status and the explanation "access to
> resource has been denied". Apparently, the user's session has been timed out
> and so he or she is no longer authorised to access the resource.
>
> 7. When I attach a debugger to the source code in my second webapp, I can
> stop execution and display context variables:
> *** HttpServletRequest.StandardSession.maxInactiveInterval has the value
> 7200 (i.e. 120 minutes),
> which is the time defined in the webapp's own xml.
>
>
> These observations suggest the session is being timed out based on the value
> for the webapp first encountered by SSO, possibly associated with the entire
> SSO Realm, and is not being modified by the individual webapps within the
> Realm.
>
> I can see some relevant logic within the source code of
> SingleSignOn.sessionEvent(SessionEvent), but I don't know which session
> instance it will be working with:
>
Sessions in each of webapps are independent from each other. That is
what Servet specification requires.
The org.apache.catalina.authenticator.SingleSignOn valve
invalidates the SSO session when session is explicitly invalidated
(that is what you usually do on logout: session.invalidate())
It tries to differentiate between explicit session invalidation and it
timing out. Timed out sessions are just removed, and invalidation
happens when the last session for the same sso id has been removed.
Maybe something goes wrong in SingleSignOn#sessionEvent(...) - you may
try to debug it (see Wiki) or at least enable debug logging for that
class.
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 11/10/11 22:24, Christopher Schultz wrote:
Super thoughts, Chris, but thanks also to everyone else who has
commented. I really appreciate everyone's contributions because (until
now) I felt I was "out there" on my own, ignorant and stupid. It is
reassuring to find that my analysis is not wildly in error. I will work
on this issue further in the hope that others might benefit from the
knowledge documented in this thread.
I'll be busy for the next couple of days, but I will definitely turn on
debugging in the Valve soon. If that doesn't reveal "the truth", then
I'll slurp a copy of the jsp's java source into my debugger and
breakpoint that (nasty) complex "if" statement to see exactly how it
handles both the timed-out Session and the associated SSO-session.
Watch this space for further enlightenment...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian,
>
> On 10/11/2011 12:35 PM, Brian Burch wrote:
>> OK, I think I understand the distinction you are making, which is
>> consistent with there being a Session array (rather than a simple
>> field) in the SingleSignOnEntry class.
>
> I haven't looked at the implementation, but it sounds plausible that a
> SingleSignOnEntry object would contain references (or ids) for each of
> the sessions that are involved in the SSO "session".
>
>> But I am having trouble understanding the life cycle of a Session.
>> If the browser has navigated away from my "static" webapp
>> container, into a completely different webapp container, why does
>> it still have an associated Session?
>
> I'm not an expert at SSO, nor have I ever used it on any of my
> projects. All my answers should be considered suspicious :)
>
> When the browser navigates away from a webapp, the webapp usually
> doesn't know, because HTTP clients generally don't ping-back pages and
> say "I'm leaving, now". That's why session timeouts exist. So, your
> client leaves the "static" webapp and 20 minutes later, the session
> timeout there kills the session, which takes-down the whole SSO "session".
>
>> I can understand how the browser would retain two Sessions if it
>> held two tabs open, one to each webapp.
>
> This happens regardless of whether the windows are still open or have
> been closed.
>
>> I guess in my situation (not everyone's), my "static" webapp is the
>> only thing that knows anything about the state of the browser, so
>> the Host and/or Valve don't know whether the browser/user will ever
>> interact with my "static" webapp again and so feel obliged to keep
>> the Session alive "just in case".
>
> Exactly. I don't believe the SSO Valve pings the various participating
> webapps just to keep their sessions alive anytime you hit a webapp
> that's part of the SSO "session" (note that I keep saying "session" in
> quotes for the SSO "session" because it's not an HttpSession, but
> there is something concrete and cohesive about all of the requests
> that come from the client that participate in that SSO).
>
>> I suppose what I really need is two levels of timeout logic: a)
>> each individual webapp already has its own session-timeout defined
>> within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL
>> Session should be invalidated.
>
> You're right: see below. Evidently, I was wrong about how this stuff
> is supposed to work.
>
>> b) SSO should only invalidate the "single sign-on" instance/entry
>> when THE FINAL webapp Session is expired or otherwise invalidated
>> (and the Session array is empty).
>
> Sorry, that's against the rules:
>
> "
> * 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. Any
> subsequent attempt to access a protected resource in any application
> will require the user to authenticate himself or herself again.
> "
>
> It doesn't specifically say so, but HttpSession timeouts in a single
> webapp does not count as "[logging] out of a web application".
>
>> Is it possible for my menu.jsp to invalidate its own Session,
>> without logging the user off, when it knows the browser will be
>> sending on a one-way trip to another webapp?
>
> If you are using FORM authentication, then session==login. If you kill
> the session, the login expires. Also, killing the session would
> take-down the SSO "session" without that helpful timeout that gets you
> the 20 minutes you already have :)
>
>> Do I need to start researching LifeCycleListeners to achieve my
>> objective, or would that be a pointless approach?
>
> Hmm... authenticator/SingleSignOn.java has this code and comment in
> the session event handler:
>
> // Was the session destroyed as the result of a timeout?
> // If so, we'll just remove the expired session from the
> // SSO. If the session was logged out, we'll log out
> // of all session associated with the SSO.
> if (((session.getMaxInactiveInterval()> 0)
> && (System.currentTimeMillis() -
> session.getThisAccessedTimeInternal()>=
> session.getMaxInactiveInterval() * 1000))
> ||
> (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) {
> removeSession(ssoId, session);
> } else {
> // The session was logged out.
> // Deregister this single session id, invalidating
> // associated sessions
> deregister(ssoId);
> }
>
> So, it looks like the Valve should *not* be expiring your SSO when the
> "static" webapp's session expires. Can you confirm that you really are
> suffering a timeout? Are there other reasons a session could be
> invalidated in any one of your webapps? The "static" one seems like
> the most likely candidate, but one of the others could be doing it.
>
> Can you enable debug logging for
> org.apache.catalina.authenticator.SingleSignOn? It looks like there
> should be lots of good logging emitted in there for you to check.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6UtBgACgkQ9CaO5/Lv0PAdpgCfRrcLaxBH3Fm/ornW1gfEjPpY
> Ay0AoLokcF2Tqm9KWEd+ORNfGMUPUmuw
> =kLUP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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: SingleSignonValve and webapp session timeout
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/12/2011 8:53 AM, Brian Burch wrote:
> My tomcat 6.0.28 compiled class for AuthenticatorBase does not
> match the 6.0.33 source code I am debugging with. The SSO Valve is
> pretty much the same.
So get the source for 6.0.28:
http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.28/src/
or
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_28/
> The 6.0.33 AuthenticatorBase.register() method has a lot of stuff
> about SSO and it mentions a bug fix number 10040 in some comments
> that sound quite relevant to my symptoms.
That bug was fixed in 2003, in TC4 and TC5. The first stable release of
TC6, 6.0.10, was released on 2007-02-28, so that shouldn't be your
problem.
> I haven't been able to reconcile the source code and can't find
> the bug report yet.
https://issues.apache.org/bugzilla/show_bug.cgi?id=10040
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6V1vAACgkQ9CaO5/Lv0PAzhwCgvn4g3oKA/02N/eFInPwE7Ifl
1vQAn0wN37DhZhQxsmsL1ZDH6HuI4tBB
=8ith
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 12/10/11 12:51, Konstantin Kolinko wrote:
> Something becomes clearer.
>
> Remembering the session as associated with ssoid is performed by
> SingleSignOn.associate(..) method. This method is called by
> AuthenticatorBase class.
>
> Those webapps with long living sessions - are they protected by
> security constraints in their web.xml?
>
> (If they are not, then authentication does not happen and their
> sessions are not associated with SSO)/
Yes, they are constrained and once the SSO has been invalidated, they
are forced through my standard login/menu mechanism by catching the 403
error status.
My tomcat 6.0.28 compiled class for AuthenticatorBase does not match the
6.0.33 source code I am debugging with. The SSO Valve is pretty much the
same.
The 6.0.33 AuthenticatorBase.register() method has a lot of stuff about
SSO and it mentions a bug fix number 10040 in some comments that sound
quite relevant to my symptoms. I haven't been able to reconcile the
source code and can't find the bug report yet.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/12 Brian Burch <br...@pingtoo.com>:
>
> I've successfully run a remote debugger session against the SingleSignOn
> Valve while it is handling my timeout scenario.
>
> Interestingly, the logic to handle the timeout of a single webapp is exactly
> as I wanted it to be... only the specific Session is removed from the array
> and the SSOEvent remains cached and valid until the array becomes empty.
> However, when the first of the two Sessions times out, the array immediately
> becomes empty and so the SSOEntry is legitimately deregistered!
>
> It seems the second, longer-lived, webapp's Session is no longer associated
> with the existing SSOEntry when the first webapp times out. I noticed the
> second Session being validated, but didn't follow that particular bit of
> logic. I will run the scenario again to see what happens when the second
> webapp is first called.
>
Something becomes clearer.
Remembering the session as associated with ssoid is performed by
SingleSignOn.associate(..) method. This method is called by
AuthenticatorBase class.
Those webapps with long living sessions - are they protected by
security constraints in their web.xml?
(If they are not, then authentication does not happen and their
sessions are not associated with SSO)/
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 13/10/11 15:14, Brian Burch wrote:
> I beleve the division of responsibilities between the AuthenticatorBase
> abstract class and its extension classes is wrong. At the moment, it is
> the responsibility of the concrete class authenticate methods to add the
> Session to the existing SingleSignOnEntry instance. In my opinion, the
> concrete class should ONLY do its authentication - the abstract class,
> possibly in a helper method, should be responsible for maintenance of
> the Session array - regardless of which <auth-method> is actually invoked.
>
> The Form, Basic and SSL Authenticators ALL manage the Sessions array
> (slightly differently) by calling the associate or reassociate method in
> the base class. Only the NoLogin class does nothing. Perhaps I should
> just "fix" NoLoginAuthenticator and leave the other 4 classes alone?
>
> What does everyone think? I'll try to draft a code change, but I don't
> want to waste my time if there is disagreement about this crucial
> division of responsibilities.
I have just realised there is another perspective to consider:
A) when the SSO Valve has been triggered by a webapp in the realm, then
I believe that ALL concrete authenticator classes MUST cause the Session
array to be managed properly.
B) when SSO is NOT in use, it might be the case that the
NoLoginAuthenticator is intended to authenticate ALL users without
challenging them, effectively causing the security contraints to be
ignored. I'm not sure whether that is true or not yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 14/10/11 04:04, Brian Burch wrote:
> I will go quiet for a few days while I checkout 6.0.28 and get it to
> build.
Phew! That took me longer than I expected.... I got 6.0.28 to build,
then ran all the unit tests, then debugged the SSO logic and started to
understand it.
Then I (coded/debugged/understood-better) for a while and eventually
arrived at a new version of NonLoginAuthenticator that did exactly what
I wanted. It is now running on my production system.
However, I wanted to make a contribution to the project and so started
stripping down my two simplest webapps as a demonstration case. I
quickly realised my fix against version 6 probably wouldn't be very
interesting to the tomcat developers, so I checked out the latest trunk
(aka version 8) and started all over again with the servlet spec 3.0.
Although the current source for NonLoginAuthenticator is identical in
the trunk, the behaviour of my webapps wasn't quite the same. It took a
while to untangle, but here is a summary of my conclusions:
1. The servlet spec states that the web.xml XML schema for
<login-config> multiplicity was changed from "optional" to "0 or more",
i.e. it has never been a mandatory element.
2. The servlet spec states the <auth-method> sub-element must be one of
the list: BASIC, DIGEST, FORM, CLIENT-CERT, or a vendor-specific
authentication scheme, i.e. tomcat's use of the internal value "NONE"
should be taken to be a vendor-specific implementation method.
3. I conclude that tomcat is correct in permitting a webapp to be
deployed under a web.xml that a) has security constraints defined, and
b) does NOT have a login-method defined. The servlet spec does not
define how this case should be implemented because it does not define an
<auth-method> of NONE.
4. Tomcat associates the
org.apache.catalina.authenticator.NonLoginAuthenticator class with a
webapp that has not defined a <login-method>. The latest (and also very
old) source has a trivial authenticate method that ALWAYS returns true.
Unfortunately, the multiple comments in the code are confusing (to me,
at least) about the semantic meaning associated with true and false
return values (see next step). However, the code that calls it in
AuthenticatorBase.invoke implies a value of true means the user is
successfully authenticated, while false implies an HTTP error status has
already been assigned to the response.
5. In the case where the SSO valve has NOT been associated with a Host,
it apparently does not matter that NonLoginAuthenticator.authenticate
always returns true (implying, I think, that the user is authenticated)
because AuthenticatorBase.invoke will eventually check whether the
resource is protected. If it is protected, then there will be no
associated java.security.Principal to provide a role that might be
permitted, and therefore access will be forbidden. (In my view, this is
the right outcome but for the wrong reason.)
6. In the case where the SSO valve is associated with the Host,
behaviour is different to step 5 above: if the remote user has already
authenticated to a different webapp, then the browser will send the SSO
cookie to all webapps in the same Realm. AuthenticatorBase will use the
cookie to find the SSOEntry instance and retrieve the associated
security Principal. This allows determination of permission to access
the constrained resource.
7. I believe there are two real (rather than philosophical) problems
with the existing logic:
7.1. Because the NonLogin webapp Session is never registered with the
existing SSOEntry, its own <session-timeout> will NOT be honoured. In
fact, once the last SSO-participating Session is expired, the NonLogin
webapp will effectively become instantly unauthenticated and so its next
protected resource access will be forbidden.
7.2. If SSO is used with a browser that does not accept cookies (I
/think/ this situation is supported), then NoLogin webapps will never be
able to "borrow" an existing SSO authentication as described in 6 above.
Have I overlooked anything important?
If I've got it right, should I tidy up and submit my demo webapps and
the proposed fix?
I haven't yet found any unit tests for the SingleSignOn valve... I would
have liked to write some tests for my proposed change, but without an
SSO environment, they (it?) would be trivial and pointless. Is the SSO
valve tested under some other framework than junit?
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 13/10/11 15:14, Brian Burch wrote:
> On 13/10/11 11:39, Brian Burch wrote:
>> To summarise: the webapp's explicit timeout is not being honoured
>> because its web.xml does not define a <login-config> section. Therefore,
>> the webapp has defaulted to use the NonLoginAuthenticator - which
>> honours the existing SSO state (via the client cookie), but does not
>> associate the Session for the second webapp with the existing SSOEvent
>> instance.
>>
>> Before I make this change, I want to satisfy myself that the
>> NonLoginAuthenticator.authenticate method is working properly according
>> to the specification.
>
How about this comment taken from NonLoginAuthenticator.authenticate()!
I hadn't noticed it when running my debugger because all comments are
greyed-out and I was concentrating on the executable code.
/* Associating this request's session with an SSO would allow
coordinated session invalidation, but should the session for
a webapp that the user didn't log into be invalidated when
another session is logged out?
String ssoId = (String) request.getNote(Constants.REQ_SSOID_NOTE);
if (ssoId != null)
associate(ssoId, getSession(request, true));
*/
I looked at the tomcat6 repository and this code has been commented out
as far back as 6.0.0. I tried looking at tomcat5, but the repository
layout is different and I couldn't even find the source for the class,
even though it must be there. I didn't try too hard, because it is
tomcat6 I am interested in - not a history lesson.
The comment above the no-op'd code doesn't make a lot of sense to me, so
I will go quiet for a few days while I checkout 6.0.28 and get it to
build. Once I can do that, I'll uncomment the "interesting" logic, build
it again. I can drop the new jar into my own tomcat server and follow
its behaviour under my debugger.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 13/10/11 11:39, Brian Burch wrote:
> To summarise: the webapp's explicit timeout is not being honoured
> because its web.xml does not define a <login-config> section. Therefore,
> the webapp has defaulted to use the NonLoginAuthenticator - which
> honours the existing SSO state (via the client cookie), but does not
> associate the Session for the second webapp with the existing SSOEvent
> instance.
>
> Before I make this change, I want to satisfy myself that the
> NonLoginAuthenticator.authenticate method is working properly according
> to the specification.
I've just checked the definition of the SSO behaviour at:
http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Single%20Sign%20On
(tomcat7 is identical). Here is the crucial extract: "All web
applications configured for this virtual host must share the same Realm."
It does NOT say all webapps must also share the same <auth-method>.
I beleve the division of responsibilities between the AuthenticatorBase
abstract class and its extension classes is wrong. At the moment, it is
the responsibility of the concrete class authenticate methods to add the
Session to the existing SingleSignOnEntry instance. In my opinion, the
concrete class should ONLY do its authentication - the abstract class,
possibly in a helper method, should be responsible for maintenance of
the Session array - regardless of which <auth-method> is actually invoked.
The Form, Basic and SSL Authenticators ALL manage the Sessions array
(slightly differently) by calling the associate or reassociate method in
the base class. Only the NoLogin class does nothing. Perhaps I should
just "fix" NoLoginAuthenticator and leave the other 4 classes alone?
What does everyone think? I'll try to draft a code change, but I don't
want to waste my time if there is disagreement about this crucial
division of responsibilities.
Once I have some sort of agreement, I'll get on with the change.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 13/10/11 05:29, Konstantin Kolinko wrote:
> What happens when an non-authenticated user accesses one of those webapps?
>
> It just rejects it with 403, or it should display a login form (and
> authenticate him/her and create a SSO cookie), or redirect to another
> webapp that has a login form?
Sorry, Konstantin, I thought I had already described that case: I've
just run it again to make absolutely sure... it definitely gets 403
status, which proves the security constraints are properly enforced when
a user is not authenticated.
The container that experiences the 403 has an error page handler for
that particular status. The error page handler is, of course,
specifically defined as permitted for GET requests from unauthenticated
users. The error page handler redirects the client browser away from the
secure container/webapp and back to the logon/menu "static" webapp.
To summarise: the webapp's explicit timeout is not being honoured
because its web.xml does not define a <login-config> section. Therefore,
the webapp has defaulted to use the NonLoginAuthenticator - which
honours the existing SSO state (via the client cookie), but does not
associate the Session for the second webapp with the existing SSOEvent
instance.
As I said before, I can fix my system behaviour quickly be defining
login-config's in each webapp to define a completely redundant FORM
login handler. That will cause the Sessions to be associated with the
SSOEvent and my required (correct) timeout behaviour will undoubtedly
follow.
Before I make this change, I want to satisfy myself that the
NonLoginAuthenticator.authenticate method is working properly according
to the specification.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/12 Brian Burch <br...@pingtoo.com>:
>
> OK, it now all makes some kind of sense. I've discovered that the Session
> associated with the second webapp is never being associated with the SSO
> instance created by the first webapp. However, the weird thing is that the
> protected resources of the second webapp are made available to the signed-on
> user through the correct SSO identity.
>
> The reason is that the web.xml of the second webapp does NOT have a
> <login-config> section at all, so an <auth-method> is not explicitly
> assigned to it. I had not realised this before, but by default the
> NoLoginAuthenticator class is used. The authenticate() method of this no-op
> class DOES NOT add the Session instance of the second webapp to the SSO
> array it has been "properly associated" with.
>
> In other words, all of my other webapps never get associated with the
> existing SSO Session array, so they all get timed-out simultaneously with
> the first one... effectively, their individual session timeouts are ignored.
>
> These non-first webapps do not have a <login-config> because users will
> NEVER be able to login to their containers - unauthenticated users will be
> redirected to the common "static" login and menu container.
>
> I'll do a bit more research on the logic within the various Authenticator
> classes to see whether the NoLoginAuthenticator is behaving "correctly",
> because I'm not convinced it is yet.
>
> Worse case: code a <login-config> section for each of my webapps, even
> though it will never be used to execute code and will only trigger the
> association of the new Session instance and therefore have it "live" under
> its own timeout and preserve the SSO instance accordingly.
What happens when an non-authenticated user accesses one of those webapps?
It just rejects it with 403, or it should display a login form (and
authenticate him/her and create a SSO cookie), or redirect to another
webapp that has a login form?
>
> Best case: either change NoLoginAuthenticator or write my own variant that
> actually makes the SSO-to-Session association that I need.
>
> (words of encouragement or enlightenment will be appreciated!)
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 12/10/11 12:35, Brian Burch wrote:
> I've successfully run a remote debugger session against the SingleSignOn
> Valve while it is handling my timeout scenario.
>
> Interestingly, the logic to handle the timeout of a single webapp is
> exactly as I wanted it to be... only the specific Session is removed
> from the array and the SSOEvent remains cached and valid until the array
> becomes empty. However, when the first of the two Sessions times out,
> the array immediately becomes empty and so the SSOEntry is legitimately
> deregistered!
>
> It seems the second, longer-lived, webapp's Session is no longer
> associated with the existing SSOEntry when the first webapp times out. I
> noticed the second Session being validated, but didn't follow that
> particular bit of logic. I will run the scenario again to see what
> happens when the second webapp is first called.
OK, it now all makes some kind of sense. I've discovered that the
Session associated with the second webapp is never being associated with
the SSO instance created by the first webapp. However, the weird thing
is that the protected resources of the second webapp are made available
to the signed-on user through the correct SSO identity.
The reason is that the web.xml of the second webapp does NOT have a
<login-config> section at all, so an <auth-method> is not explicitly
assigned to it. I had not realised this before, but by default the
NoLoginAuthenticator class is used. The authenticate() method of this
no-op class DOES NOT add the Session instance of the second webapp to
the SSO array it has been "properly associated" with.
In other words, all of my other webapps never get associated with the
existing SSO Session array, so they all get timed-out simultaneously
with the first one... effectively, their individual session timeouts are
ignored.
These non-first webapps do not have a <login-config> because users will
NEVER be able to login to their containers - unauthenticated users will
be redirected to the common "static" login and menu container.
I'll do a bit more research on the logic within the various
Authenticator classes to see whether the NoLoginAuthenticator is
behaving "correctly", because I'm not convinced it is yet.
Worse case: code a <login-config> section for each of my webapps, even
though it will never be used to execute code and will only trigger the
association of the new Session instance and therefore have it "live"
under its own timeout and preserve the SSO instance accordingly.
Best case: either change NoLoginAuthenticator or write my own variant
that actually makes the SSO-to-Session association that I need.
(words of encouragement or enlightenment will be appreciated!)
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 11/10/11 22:24, Christopher Schultz wrote:
> I'm not an expert at SSO, nor have I ever used it on any of my
> projects. All my answers should be considered suspicious :)
>
> So, it looks like the Valve should *not* be expiring your SSO when the
> "static" webapp's session expires. Can you confirm that you really are
> suffering a timeout? Are there other reasons a session could be
> invalidated in any one of your webapps? The "static" one seems like
> the most likely candidate, but one of the others could be doing it.
>
> Can you enable debug logging for
> org.apache.catalina.authenticator.SingleSignOn? It looks like there
> should be lots of good logging emitted in there for you to check.
It was late at night when I said the SSO Valve was a jsp. Thanks for not
pointing out my mistake!
I've successfully run a remote debugger session against the SingleSignOn
Valve while it is handling my timeout scenario.
Interestingly, the logic to handle the timeout of a single webapp is
exactly as I wanted it to be... only the specific Session is removed
from the array and the SSOEvent remains cached and valid until the array
becomes empty. However, when the first of the two Sessions times out,
the array immediately becomes empty and so the SSOEntry is legitimately
deregistered!
It seems the second, longer-lived, webapp's Session is no longer
associated with the existing SSOEntry when the first webapp times out. I
noticed the second Session being validated, but didn't follow that
particular bit of logic. I will run the scenario again to see what
happens when the second webapp is first called.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/11/2011 12:35 PM, Brian Burch wrote:
> OK, I think I understand the distinction you are making, which is
> consistent with there being a Session array (rather than a simple
> field) in the SingleSignOnEntry class.
I haven't looked at the implementation, but it sounds plausible that a
SingleSignOnEntry object would contain references (or ids) for each of
the sessions that are involved in the SSO "session".
> But I am having trouble understanding the life cycle of a Session.
> If the browser has navigated away from my "static" webapp
> container, into a completely different webapp container, why does
> it still have an associated Session?
I'm not an expert at SSO, nor have I ever used it on any of my
projects. All my answers should be considered suspicious :)
When the browser navigates away from a webapp, the webapp usually
doesn't know, because HTTP clients generally don't ping-back pages and
say "I'm leaving, now". That's why session timeouts exist. So, your
client leaves the "static" webapp and 20 minutes later, the session
timeout there kills the session, which takes-down the whole SSO "session".
> I can understand how the browser would retain two Sessions if it
> held two tabs open, one to each webapp.
This happens regardless of whether the windows are still open or have
been closed.
> I guess in my situation (not everyone's), my "static" webapp is the
> only thing that knows anything about the state of the browser, so
> the Host and/or Valve don't know whether the browser/user will ever
> interact with my "static" webapp again and so feel obliged to keep
> the Session alive "just in case".
Exactly. I don't believe the SSO Valve pings the various participating
webapps just to keep their sessions alive anytime you hit a webapp
that's part of the SSO "session" (note that I keep saying "session" in
quotes for the SSO "session" because it's not an HttpSession, but
there is something concrete and cohesive about all of the requests
that come from the client that participate in that SSO).
> I suppose what I really need is two levels of timeout logic: a)
> each individual webapp already has its own session-timeout defined
> within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL
> Session should be invalidated.
You're right: see below. Evidently, I was wrong about how this stuff
is supposed to work.
> b) SSO should only invalidate the "single sign-on" instance/entry
> when THE FINAL webapp Session is expired or otherwise invalidated
> (and the Session array is empty).
Sorry, that's against the rules:
"
* 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. Any
subsequent attempt to access a protected resource in any application
will require the user to authenticate himself or herself again.
"
It doesn't specifically say so, but HttpSession timeouts in a single
webapp does not count as "[logging] out of a web application".
> Is it possible for my menu.jsp to invalidate its own Session,
> without logging the user off, when it knows the browser will be
> sending on a one-way trip to another webapp?
If you are using FORM authentication, then session==login. If you kill
the session, the login expires. Also, killing the session would
take-down the SSO "session" without that helpful timeout that gets you
the 20 minutes you already have :)
> Do I need to start researching LifeCycleListeners to achieve my
> objective, or would that be a pointless approach?
Hmm... authenticator/SingleSignOn.java has this code and comment in
the session event handler:
// Was the session destroyed as the result of a timeout?
// If so, we'll just remove the expired session from the
// SSO. If the session was logged out, we'll log out
// of all session associated with the SSO.
if (((session.getMaxInactiveInterval() > 0)
&& (System.currentTimeMillis() -
session.getThisAccessedTimeInternal() >=
session.getMaxInactiveInterval() * 1000))
||
(Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) {
removeSession(ssoId, session);
} else {
// The session was logged out.
// Deregister this single session id, invalidating
// associated sessions
deregister(ssoId);
}
So, it looks like the Valve should *not* be expiring your SSO when the
"static" webapp's session expires. Can you confirm that you really are
suffering a timeout? Are there other reasons a session could be
invalidated in any one of your webapps? The "static" one seems like
the most likely candidate, but one of the others could be doing it.
Can you enable debug logging for
org.apache.catalina.authenticator.SingleSignOn? It looks like there
should be lots of good logging emitted in there for you to check.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UtBgACgkQ9CaO5/Lv0PAdpgCfRrcLaxBH3Fm/ornW1gfEjPpY
Ay0AoLokcF2Tqm9KWEd+ORNfGMUPUmuw
=kLUP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by André Warnier <aw...@ice-sa.com>.
Brian Burch wrote:
...
>
> But I am having trouble understanding the life cycle of a Session. If
> the browser has navigated away from my "static" webapp container, into a
> completely different webapp container, why does it still have an
> associated Session?
Probably because the first webapp has no idea that the browser has "navigated away".
How would it know ? When the browser "navigates away", it does not send any information
to the webapp it navigated away from, saying "hey, I am navigating away from you".
It just does not send anything anymore to that webapp, and sends something to another
webapp instead (or to www.google.com).
But for the first webapp, that is the same situation as if the browser stayed on the same
page, and the user went away for lunch for half an hour (or in my country, more like two
and a half hours).
I can understand how the browser would retain two
> Sessions if it held two tabs open, one to each webapp.
The browser does not "retain sessions". What is retaining sessions, is the server.
The browser may just keep some "token" received from the server (be it a cookie, or a
session-id embedded in links contained in the currently displayed page), but that's it.
When (and if) the browser ever accesses that same server again (and the same path on the
server), it may send this token along with the new request. When the server receives a
request with such a token, it /may/ be able to use the information in the token, to
reconnect this request with some session information that it has kept until then, and thus
retrieve the session's state, and process the request "knowing" that it is the
continuation of a session (instead of back from zero).
...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
Posted by Brian Burch <br...@pingtoo.com>.
On 11/10/11 16:27, Christopher Schultz wrote:
Thanks very much for your speedy and informative reply, Christopher.
While my question is fresh in your mind, I hope you will not mind too
much if I ask a couple of relevant questions to clarify your answers below.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian,
>
> On 10/11/2011 10:09 AM, Brian Burch wrote:
>> 6. The user tries to refresh the second webapp's page after about
>> 25 minutes, but the GET fails with 403 status and the explanation
>> "access to resource has been denied". Apparently, the user's
>> session has been timed out and so he or she is no longer authorised
>> to access the resource.
>
> This sounds like expected behavior to me: sessions are distinct
> between webapps, even when SSO is being used. That means that the
> user's session in the "static" webapp will expire 20 minutes after
> their last request to "static", regardless of activity in other
> webapps. When that session times-out, the requirements of SSO are that
> all webapps participating in the SSO session are terminated.
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single%20Sign%20On
>
>> These observations suggest the session is being timed out based on
>> the value for the webapp first encountered by SSO, possibly
>> associated with the entire SSO Realm, and is not being modified by
>> the individual webapps within the Realm.
>
> I think the thing you're missing is that it's not a single session,
> it's a single sign-on. The sessions themselves are distinct.
OK, I think I understand the distinction you are making, which is
consistent with there being a Session array (rather than a simple field)
in the SingleSignOnEntry class.
But I am having trouble understanding the life cycle of a Session. If
the browser has navigated away from my "static" webapp container, into a
completely different webapp container, why does it still have an
associated Session? I can understand how the browser would retain two
Sessions if it held two tabs open, one to each webapp. I guess in my
situation (not everyone's), my "static" webapp is the only thing that
knows anything about the state of the browser, so the Host and/or Valve
don't know whether the browser/user will ever interact with my "static"
webapp again and so feel obliged to keep the Session alive "just in case".
I suppose what I really need is two levels of timeout logic:
a) each individual webapp already has its own session-timeout defined
within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL
Session should be invalidated.
b) SSO should only invalidate the "single sign-on" instance/entry when
THE FINAL webapp Session is expired or otherwise invalidated (and the
Session array is empty).
Is it possible for my menu.jsp to invalidate its own Session, without
logging the user off, when it knows the browser will be sending on a
one-way trip to another webapp? My feeling is "no" because that would
leave the SSO instance without any active Sessions until the new webapp
starts serving the client.
Do I need to start researching LifeCycleListeners to achieve my
objective, or would that be a pointless approach?
>> Regardless of my open question, **something** has been waiting for
>> a timer to pop. The timer must have been set to 20 minutes at the
>> time it was scheduled, and the session has already been timed-out.
>>
>> I can see that a SingleSignOnEntry cache entry has an array to
>> carry multiple Session instances. I wonder whether the "wrong"
>> Session instance (i.e. not the one currently in conversation with
>> the client) has been used to establish the timer?
>>
>> I have read the explanation for the
>> org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it
>> doesn't really make a lot of sense to me and I'm not sure whether
>> it is relevant to my problem.
>
> I don't believe it's relevant.
>
>> Does my description make sense? I'm not sure whether I am looking
>> at a bug, or simply a case of how it is intended to work. Does
>> anyone have any helpful suggestions about how to achieve my desired
>> behaviour?
>
> I think you have two options:
>
> 1. Configure your session timeouts differently
>
> 2. Have each webapp ping the others periodically, or whenever a
> request comes in for a particular session
>
> The difficult part about #1 is that a user could use a webapp for 4
> hours and that's an unreasonable timeout for a session. You could wait
> for authentication, then increase the timeout, but you still have the
> same problem for legitimate users.
>
> #2 requires that you have webapps communicate with each other and
> masquerade as the user in question. There may be performance and
> security issues that you'll want to sort-out before you decide to do
> this kind of thing.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6UYHAACgkQ9CaO5/Lv0PDB6wCfX3pAFtu4Dhvd1I4ObIa7bR6v
> s30An1lMjyuEkth0R97atkiyGm1JNALe
> =9m7N
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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: SingleSignonValve and webapp session timeout
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/11/2011 10:09 AM, Brian Burch wrote:
> 6. The user tries to refresh the second webapp's page after about
> 25 minutes, but the GET fails with 403 status and the explanation
> "access to resource has been denied". Apparently, the user's
> session has been timed out and so he or she is no longer authorised
> to access the resource.
This sounds like expected behavior to me: sessions are distinct
between webapps, even when SSO is being used. That means that the
user's session in the "static" webapp will expire 20 minutes after
their last request to "static", regardless of activity in other
webapps. When that session times-out, the requirements of SSO are that
all webapps participating in the SSO session are terminated.
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single%20Sign%20On
> These observations suggest the session is being timed out based on
> the value for the webapp first encountered by SSO, possibly
> associated with the entire SSO Realm, and is not being modified by
> the individual webapps within the Realm.
I think the thing you're missing is that it's not a single session,
it's a single sign-on. The sessions themselves are distinct.
> Regardless of my open question, **something** has been waiting for
> a timer to pop. The timer must have been set to 20 minutes at the
> time it was scheduled, and the session has already been timed-out.
>
> I can see that a SingleSignOnEntry cache entry has an array to
> carry multiple Session instances. I wonder whether the "wrong"
> Session instance (i.e. not the one currently in conversation with
> the client) has been used to establish the timer?
>
> I have read the explanation for the
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it
> doesn't really make a lot of sense to me and I'm not sure whether
> it is relevant to my problem.
I don't believe it's relevant.
> Does my description make sense? I'm not sure whether I am looking
> at a bug, or simply a case of how it is intended to work. Does
> anyone have any helpful suggestions about how to achieve my desired
> behaviour?
I think you have two options:
1. Configure your session timeouts differently
2. Have each webapp ping the others periodically, or whenever a
request comes in for a particular session
The difficult part about #1 is that a user could use a webapp for 4
hours and that's an unreasonable timeout for a session. You could wait
for authentication, then increase the timeout, but you still have the
same problem for legitimate users.
#2 requires that you have webapps communicate with each other and
masquerade as the user in question. There may be performance and
security issues that you'll want to sort-out before you decide to do
this kind of thing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYHAACgkQ9CaO5/Lv0PDB6wCfX3pAFtu4Dhvd1I4ObIa7bR6v
s30An1lMjyuEkth0R97atkiyGm1JNALe
=9m7N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org