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
