Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SingleSignonValve and webapp session timeout
-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:
Re: SingleSignonValve and webapp session timeout
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)) ||
