Re: [5] [Proposal] Adding an authorization interface

[Jeanfrancois Arcand]

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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>