Costin Manolache wrote:
Jeanfrancois Arcand wrote:Because you can start using the java.security.Provider.checkPermission for granting/denying resources.
Costin Manolache wrote:I was thinking at authentication ( this is the main use of Realm AFAIK ).
IMO - I would rather see us using JAAS directly as APICan you elaborate a little more? JAAS will certainly help for user/group
instead of defining our own.
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:
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)Why would someone use this instead of web.xml ?
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:
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.
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 ).
You cannot grant/denied URL using JAAS as it is right now. In order to achieve that, you need something like JSR 115.
(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 115What's wrong with using JAAS as an "interface" ? After all that's the purpose of JAAS - an interface for authorization ( and authentication ).
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'm not sure we're talking about the same things.
I already mentioned that I would preffer using JNDI forAuthorizer and AuthorizerBase (proper english this time :-) ) are not
abstracting the informations about user/group. In general, the
fewer interfaces we define, the better it is.
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.
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.
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.
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
