tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <jfarc...@apache.org>
Subject Re: [5] [Proposal] Adding an authorization interface
Date Thu, 28 Nov 2002 18:48:52 GMT


Costin Manolache wrote:

>Jeanfrancois Arcand wrote:
>
>
>  
>
>>>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.
>
Just downloaded 3.3 code base. I will take a look at the way it work. I 
not familiar with 3.3 code base.

>
> 
>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.
>
Let me learn in more detail the coyote stuff and think about it. I was 
trying to align the change with the current Valve/Realm implementation, 
but exploring other avenues for sure will help defining a better design. 
I will come back soon on the subject.....

>
>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 agree. If It possible, I will come up with an ActionCode. If not, then 
we should use the Authorizer idea.

Thanks,

-- Jeanfrancois

>  
>
>
>Costin
>
>
>
>
>
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message