tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [5] [Proposal] Adding an authorization interface
Date Thu, 28 Nov 2002 16:42:05 GMT
Costin Manolache wrote:
> Jeanfrancois Arcand wrote:

Sorry, I missed the first part of the discussion.

>>>Why would someone use this instead of web.xml ?
>>Because you can start using the
>>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.

I'll only be talking about HTTP authentication and the interaction with 
the realms for now.

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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message