tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <>
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 

ex (for the admin tool)

grant  codeBase "file://admin" , principal 
org.apache.catalina.realm.GenericRealm "tomcat" {
        // Role Mapped for this Grant : admin
        permission "*.jsp" , 
        // Role Mapped for this Grant : admin
        permission "action" , 
        // Role Mapped for this Grant : admin
        permission "*.html" , 
        // Role Mapped for this Grant : admin
        permission "*.do" , 

will get translated to, 
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?


-- Jeanfrancois 

>Jeanfrancois Arcand wrote:
>>I would like to propose the following re-factorisation of the current
>>Realm interface. Righ now, Realm contains 3 methods related to
>>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
>>    public boolean hasRolePermission(HttpRequest request,
>>                                                        HttpResponse
>>                                                        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
>>What do you think?
>>-- Jeanfrancois
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

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