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
