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 02:33:42 GMT


Costin Manolache wrote:

>Jeanfrancois Arcand wrote:
>
>  
>
>>Costin Manolache wrote:
>>
>>    
>>
>>>IMO  - I would rather see us using JAAS directly as API
>>>instead of defining our own.
>>>
>>>      
>>>
>>Can you elaborate a little more? JAAS will certainly help for user/group
>>authentication/authorization, but I don't think you can use it for
>>granting/denying web resources (JSR 115 is exactly doing that). With
>>115, you can use the normal policy statement to grant web resources
>>permission:
>>    
>>
>
>I was thinking at authentication ( this is the main use of Realm AFAIK ).
>
>JAAS is also used for authorization ( I don't know about JSR115),
>but in tomcat case the mapper and the web.xml stuff controls this,
>and I don't see any good reason to change this.
>
>
>  
>
>>ex (for the admin tool)
>>
>>grant  codeBase "file://admin" , principal
>>org.apache.catalina.realm.GenericRealm "tomcat" {
>>   
>>        // Role Mapped for this Grant : admin
>>        permission javax.security.jacc.WebResourcePermission "*.jsp" ,
>>"DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE";
>>        // Role Mapped for this Grant : admin
>>        permission javax.security.jacc.WebRoleRefPermission "action" ,
>>"admin";
>>        // Role Mapped for this Grant : admin
>>        permission javax.security.jacc.WebResourcePermission "*.html" ,
>>"DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE";
>>        // Role Mapped for this Grant : admin
>>        permission javax.security.jacc.WebResourcePermission "*.do" ,
>>"DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE";
>>    };
>>
>>will get translated to javax.security.jacc.WebResourcePermission,
>>WebRoleRefPermission and WebUserDataPermission. In order to only use
>>JAAS, we will have to:
>>    
>>
>
>Why would someone use this instead of web.xml ? 
>
Because you can start using the java.security.Provider.checkPermission 
for granting/denying resources.

>
>I don't mind having the security config consistent with the policy 
>( I never liked how it's done in web.xml ). However at least from my
>point of view the more interesting issue is integrating with the web
>server semantics and syntax ( and how to write the authorization 
>definition in httpd.conf ).
>
I agree and I would like to work also on it....but I think we don't 
speak about the same level of authentication. I mean URL autorization, 
i.e. the way we , at runtime, enforce the security constraint defined in 
web.xml.

>
>
>  
>
>>(1) Associate the Subject with an access control context (already done
>>in Tomcat 5)
>>(2) Define are own set of permission object/mapping.
>>    
>>
>
>
> 
>  
>
>>If we decide to go with only JAAS, then I recommend we use JSR 115
>>instead of redefining something. But I would prefer opening the API for
>>other technologies instead of limitating us with JAAS. Of course we can
>>ship with a JAAS/115 default implementation. Between Tomcat and JAAS, we
>>will need an "interface". That's what I'm proposing. Righ now both
>>authentication and authorization are in Realm.
>>    
>>
>
>What's wrong with using JAAS as an "interface" ? After all that's 
>the purpose of JAAS - an interface for authorization ( and authentication ).
>
>I'm not sure we're talking about the same things.
>
You cannot grant/denied URL using JAAS as it is right now. In order to 
achieve that, you need something like JSR 115.

>  
>
>
>
>  
>
>>>I already mentioned that I would preffer using JNDI for
>>>abstracting the informations about user/group. In general, the
>>>fewer interfaces we define, the better it is.
>>>
>>>      
>>>
>>Authorizer and AuthorizerBase (proper english this time :-) ) are not
>>about user/group, but about granting web resources to user and group.
>>JNDI can used for replacing/improving the Realm implementation, but IMO
>>not to grant/denied web resources (OK we can always define our JNDI
>>permissions). Is that was you mean or do I miss something with JNDI?
>>    
>>
>
>I mentioned JNDI as an API to access (abstract) information about users.
>JAAS for authentication.
>
+1...but this is not related to my proposal.

>
>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).

Thanks

-- Jeanfrancois

>
>Since the problem of mapping this into httpd.conf semantics is alrady
>very complex ( and not completely resolved), I would need a lot of arguments
>in opening this up to arbitrary user code - that would be close to 
>impossible to integrate with the web server and have consistent behavior.
>
>Having the web server call tomcat for each static page in order to call
>this authorization hook is not acceptable.
>
>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