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
