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 01:23:58 GMT


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:

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:

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


>
>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?

Thanks,

-- Jeanfrancois 

>
>Costin
>
>Jeanfrancois Arcand wrote:
>
>  
>
>>Hi,
>>
>>I would like to propose the following re-factorisation of the current
>>Realm interface. Righ now, Realm contains 3 methods related to
>>authorization:
>>
>>hasRole
>>hasUserDataPermission
>>hasResourcePermission
>>
>>I would like to create a new interface called Authorizator(and a default
>>AuthorizatorBase) that will take care of those methods. I just think
>>those methods should be grouped together, and I think they are not
>>directly related to the Realm "concepts" (better separation of
>>concepts). It will allows peoples to change the current resource
>>authorization mechanism without having to modify the Realm interface.
>>
>>Precisely, the method will have the following signature:
>>
>>    public boolean hasResourcePermission(HttpRequest request,
>>                                                                
>>HttpResponse response,
>>                                                                
>>SecurityConstraint constraint,
>>                                                                Context
>>context)
>>   
>>    public boolean hasRolePermission(HttpRequest request,
>>                                                        HttpResponse
>>response,
>>                                                        String role);
>>
>>    public boolean hasUserDataPermission(HttpRequest request,
>>                                         HttpResponse response,
>>                                         SecurityConstraint constraint,
>>                                         Context context)
>>
>>In the current implementation, those methods  will get invoked by the
>>AuthenticatorBase and when the user call isUserInRole().
>>
>>This factorisation will provide the ability to replace/extend the
>>default AuthorizatorBase (that implement the Servlet
>><security-constraint> stuffs...section SRV 12.7) by another mechanism:
>>LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be
>>able to grant/denied permissions not only based on the web.xml content,
>>but also using other technologies. Althrough it is possible to do that
>>with the current Tomcat 5 codebase, I recommend we create this extra
>>interface. For J2EE 1.4, I was able to implement JSR 115 without having
>>to much problems, but I'm sure having a specialized interface will make
>>implementation easier.
>>
>>The Realm.hasRole will be deprecated in order to achieve that
>>re-factorisation.
>>
>>What do you think?
>>
>>Thanks,
>>
>>-- Jeanfrancois
>>    
>>
>
>
>
>
>--
>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