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

[Jeanfrancois Arcand]

Costin Manolache wrote:

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.

Just downloaded 3.3 code base. I will take a look at the way it work. I not familiar with 3.3 code base.

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.

Let me learn in more detail the coyote stuff and think about it. I was trying to align the change with the current Valve/Realm implementation, but exploring other avenues for sure will help defining a better design. I will come back soon on the subject.....

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.

I agree. If It possible, I will come up with an ActionCode. If not, then we should use the Authorizer idea.

Thanks,

-- Jeanfrancois

Costin









--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>