Jeanfrancois Arcand wrote:
>
>
> 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:
I was thinking at authentication ( this is the main use of Realm AFAIK ).
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)
>
> 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:
Why would someone use this instead of 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 ).
> (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.
What's wrong with using JAAS as an "interface" ? After all that's
the purpose of JAAS - an interface for authorization ( and authentication ).
I'm not sure we're talking about the same things.
>>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?
I mentioned JNDI as an API to access (abstract) information about users.
JAAS for authentication.
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.
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]>
