Costin Manolache wrote:
Jeanfrancois Arcand wrote:
Sorry, I missed the first part of the discussion.
I'll only be talking about HTTP authentication and the interaction with the realms for now.Why would someone use this instead of web.xml ?Because you can start using the java.security.Provider.checkPermission for granting/denying resources.
Not sure this would be the most efficient solution - the mapper is
( or will be ) optimized on the way it is used in tomcat. But I see your point - and I think it would be nice to use similar concepts or API.
If by authorization you mean deciding in an URL can be accessed by a user - I think the mapper ( or a similar valve ) is the best solution, using the informations in web.xml.Exactly. The "similar valve" :-) is the AuthenticatorBase, who delegate part of the authorization decision to the RealmBase, as well as part of authentication. I'm +1 to delegate the authentication to the RealBase, but -1 to delegate the authorization (this is how it is implemented right now). What I recommend is to remove the authorization code from the RealmBase and move it to the AutorizerBase. It's just refactoring one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS, etc.) in a "cleaner" way. Using JAAS as an interface will have to happen somewhere in AuthenticatorBase & RealmBase. Since in JAAS there is a clear separation between authentication/autorization, why not have the same separation in Tomcat by having Realm & Authorizer (instead of only Realm).
I agree that "authenticate" and "authorize" are 2 different hooks and need
to be separated.
Let me think about it - and maybe get some other opinions.
I would very much preffer a consistent mechanism for all the hooks in tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all
the possible hooks are defined ( with a number of problems we already
know regarding ordering, but that's a different issue ). In 4.x Valves
are used as the main extension mechanism, but also Listeners, Realms, Connectors and few other interfaces - and I would very much prefer
a solution that is more consistent and simpler.
For example - move it at Coyote level and use an ActionCode for authorization. Things are not very well defined for chaining the coyote actions, but it can be done easily.
All hooks could be defined as coyote Actions - instead of having a specific Authorizer interface you'll have an authorizer action.
Does it sound acceptable ? I would mention that this is how authorization is implemented in apache ( and most web servers ), and it would probably
make it easier to integrate.
Well, there is just a style difference between having a generic hook
and having one specific interface like Authorizer, but for a lot of people
understanding the hook mechanism and the particular hooks is easier than
dealing with dozens of slightly different interfaces.
The main problem is that some authentication schemes need the realm to function (digest, for example). So I don't see how we can put that layer of processing in Coyote, since we need access to the realm to perform it. However, the code in the current authenticators will enventually be rewritten Coyote-style (and using tomcat-util objects) so that it actually performs well.
I think a refactoring of the realms is needed in order to support any auth scheme (most realms don't work with digest). To be able to do digest and basic using the same realm, one need either:
- the clear text password of the user (not good for security)
- the limited digest (I think that's how it's called in the HTTP Auth RFC; look there for more details)
We should probably standardize on storing the limited digest defined in the RFC in the realms instead of the clear password or some kind of unusable digest of the password.
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
