Jeanfrancois Arcand wrote:
>>Why would someone use this instead of web.xml ? >> > Because you can start using the java.security.Provider.checkPermission > for granting/denying resources. Not sure this would be the most efficient solution - the mapper is ( or will be ) optimized on the way it is used in tomcat. But I see your point - and I think it would be nice to use similar concepts or API. >>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. >> > 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. > > 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). I agree that "authenticate" and "authorize" are 2 different hooks and need to be separated. Let me think about it - and maybe get some other opinions. I would very much preffer a consistent mechanism for all the hooks in tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all the possible hooks are defined ( with a number of problems we already know regarding ordering, but that's a different issue ). In 4.x Valves are used as the main extension mechanism, but also Listeners, Realms, Connectors and few other interfaces - and I would very much prefer a solution that is more consistent and simpler. For example - move it at Coyote level and use an ActionCode for authorization. Things are not very well defined for chaining the coyote actions, but it can be done easily. All hooks could be defined as coyote Actions - instead of having a specific Authorizer interface you'll have an authorizer action. Does it sound acceptable ? I would mention that this is how authorization is implemented in apache ( and most web servers ), and it would probably make it easier to integrate. Well, there is just a style difference between having a generic hook and having one specific interface like Authorizer, but for a lot of people understanding the hook mechanism and the particular hooks is easier than dealing with dozens of slightly different interfaces. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
