Sorry to be late commenting on this. I have been busy with non Tomcat stuff. I have read most of the thread and just picked the original proposal to reply to.
I agree that authentication and authorization should be split out into separate interfaces. I also think it would be nice if the web server (especially Apache) could work seemlessly with Tomcat realm based authentication for when you use Apache to serve static content. I think Costin raised this point. I have some other issues with realm based authentication as currently implemented. There are a number of different types of realm implementations in org.apache.catalina.realm. These are all solely used for web application realm based authentication except for those which implement the UserDatabase which understands users, groups, and roles and has methods for managing these. Also a UserDatabase can be instantiated as a JNDI resource. It would be nice if all realm implementations could support not only authentication and authorization but also management of users, groups, and roles. And be instantiated as a JNDI resource so it can be provided by the container as a resource to a virtual host. This would allow adding support to the web application manager for user management so that a virtual host could manage their own universe of users. Or even integrate this into their own web application. This would require extending the JndiPermission custom SecurityManager permission to support read/write of a realm JNDI resource. And putting the interfaces for using the realms in a package such as org.apache.realm so that web applications can use the interface for managing users without having to grant a RuntimePermission accessClassInPackage for org.apache.catalina.realm. Regards, Glenn 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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
