You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jeanfrancois Arcand <jf...@apache.org> on 2002/11/27 22:36:24 UTC
[5] [Proposal] Adding an authorization interface
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Costin Manolache <cm...@yahoo.com>.
Glenn Nielsen wrote:
> 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.
Requiring all realm implementations to support user management is
not a good idea. Some realms can do that ( database, our own file, ldap)
and some just can't ( passwd, kerberos/radius/tacacs, etc ).
I think we have 3 distinct issues:
- authorization: I think tomcat needs to expose a single hook and provide
a default implementation ( using the mapper - it can also implement jsr115,
but it needs to be efficient )
- authentication: again one hook that could be implemented by delegating
to apache or use JAAS ( that should be the default - and all current
Realms migrated to JAAS plugins ! )
- user management. That should be optional - and probably the best
abstraction is JNDI. Besides user/pass/certificate it can store all other
user attributes. I think we should be consistent on naming the attributes
as in the inetUser LDAP schema ( it will work out-of-box with existing
ldap servers and easy to translate to databases, etc ). All UserDatabase
impl should be migrated to JNDI providers, and UserDatabase deprecated (
or implemented on top of jndi ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Glenn Nielsen <gl...@mail.more.net>.
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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Costin Manolache <cm...@yahoo.com>.
Jeanfrancois Arcand wrote:
>>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.
The important codebase to take a look at is Apache2 :-) You can also
check axis, they have a very nice hook mechanism ( very similar with
apache2 and everything else, but the java implementation is quite good ).
Tomcat3.3 is a bit closer to apache1.3 modules ( one interface, one
method per hook chain ), and it has the same limitations.
The idea is quite simple: have a consistent API for all supported hooks.
Chain + Handler or whatever name is used is fine. Both iterative
and recursive ( Valve ) are fine ( and can be used in the same chain !).
> I agree. If It possible, I will come up with an ActionCode. If not, then
> we should use the Authorizer idea.
I'm very sure it is possible ( with some extensions to Action maybe, but
it's the same thing ). The pattern is used in a lot of projects and
most servers I know.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Jeanfrancois Arcand <jf...@apache.org>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: [5] [Proposal] Adding an authorization interface
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>I'll only be talking about HTTP authentication and the interaction with
>>the realms for now.
>>
>>The main problem is that some authentication schemes need the realm to
>>function (digest, for example). So I don't see how we can put that layer
>>of processing in Coyote, since we need access to the realm to perform
>>it. However, the code in the current authenticators will enventually be
>>rewritten Coyote-style (and using tomcat-util objects) so that it
>>actually performs well.
>
>
> That's orthogonal and not the subject of this discussion ( the proposal
> is about authorization, not authentication ).
Yes, I know ;-) It's not too often that people talk about refactoring
that part of Tomcat, so I wanted to mention that issue.
> Also the issue of using coyote hooks ( Action ) or a custom interface is
> orthogonal on what information is needed, in both cases the implementation
> of the authentication hook ( or interface ) will have access to the same
> information ( Request, user info, etc ).
Yes, you can indeed pass the necessary information as a parameter.
>>I think a refactoring of the realms is needed in order to support any
>>auth scheme (most realms don't work with digest). To be able to do
>
>
> +1.
>
> I would add to the wish list better support for web server integration.
> It would be nice ( at least for jni mode ) to be able to have the
> native server call the hook to auth static resources - but the real
> important thing is allow the native server do it ( and the countless auth
> modules ).
>
>
>
>>We should probably standardize on storing the limited digest defined in
>>the RFC in the realms instead of the clear password or some kind of
>>unusable digest of the password.
>
>
> I like the move to split the storage of the info about user from Realm,
> as well as the split of authorization/authentication. I don't like
> the current abstraction for user info ( and the fact that all users
> need to be in memory ), and I would preffer use of a consistent hook
> mechanism ( coyote Action ) instead of special interfaces.
I don't care that much about the hook mechanism (the current one works
ok), but the user storage is certainly broken, and this part of Tomcat
could generally be more elegant (but maybe something implementing FORM
cannot be made to be elegant :-P ).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> I'll only be talking about HTTP authentication and the interaction with
> the realms for now.
>
> The main problem is that some authentication schemes need the realm to
> function (digest, for example). So I don't see how we can put that layer
> of processing in Coyote, since we need access to the realm to perform
> it. However, the code in the current authenticators will enventually be
> rewritten Coyote-style (and using tomcat-util objects) so that it
> actually performs well.
That's orthogonal and not the subject of this discussion ( the proposal
is about authorization, not authentication ).
Also the issue of using coyote hooks ( Action ) or a custom interface is
orthogonal on what information is needed, in both cases the implementation
of the authentication hook ( or interface ) will have access to the same
information ( Request, user info, etc ).
> I think a refactoring of the realms is needed in order to support any
> auth scheme (most realms don't work with digest). To be able to do
+1.
I would add to the wish list better support for web server integration.
It would be nice ( at least for jni mode ) to be able to have the
native server call the hook to auth static resources - but the real
important thing is allow the native server do it ( and the countless auth
modules ).
> We should probably standardize on storing the limited digest defined in
> the RFC in the realms instead of the clear password or some kind of
> unusable digest of the password.
I like the move to split the storage of the info about user from Realm,
as well as the split of authorization/authentication. I don't like
the current abstraction for user info ( and the fact that all users
need to be in memory ), and I would preffer use of a consistent hook
mechanism ( coyote Action ) instead of special interfaces.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Jeanfrancois Arcand wrote:
Sorry, I missed the first part of the discussion.
>>>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.
I'll only be talking about HTTP authentication and the interaction with
the realms for now.
The main problem is that some authentication schemes need the realm to
function (digest, for example). So I don't see how we can put that layer
of processing in Coyote, since we need access to the realm to perform
it. However, the code in the current authenticators will enventually be
rewritten Coyote-style (and using tomcat-util objects) so that it
actually performs well.
I think a refactoring of the realms is needed in order to support any
auth scheme (most realms don't work with digest). To be able to do
digest and basic using the same realm, one need either:
- the clear text password of the user (not good for security)
- the limited digest (I think that's how it's called in the HTTP Auth
RFC; look there for more details)
We should probably standardize on storing the limited digest defined in
the RFC in the realms instead of the clear password or some kind of
unusable digest of the password.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>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 ?
>
Because you can start using the java.security.Provider.checkPermission
for granting/denying resources.
>
>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 ).
>
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.
>
>
>
>
>>(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.
>
You cannot grant/denied URL using JAAS as it is right now. In order to
achieve that, you need something like JSR 115.
>
>
>
>
>
>
>>>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.
>
+1...but this is not related to my proposal.
>
>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).
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: [5] [Proposal] Adding an authorization interface
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by Jeanfrancois Arcand <jf...@apache.org>.
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:
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:
(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.
>
>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?
Thanks,
-- Jeanfrancois
>
>Costin
>
>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: [5] [Proposal] Adding an authorization interface
Posted by Costin Manolache <cm...@yahoo.com>.
IMO - I would rather see us using JAAS directly as API
instead of defining our own.
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.
Costin
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5] [Proposal] Adding an authorization interface
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 27 Nov 2002, Jeanfrancois Arcand wrote:
> I would like to create a new interface called Authorizator(and a default
> AuthorizatorBase) that will take care of those methods.
I'd be a lot more willing to buy in to Authorizer and AuthorizerBase :-).
The initial Realm design definitely combined the concepts of
authentication and authorization. Since the current direction in Java
APIs seems to be to split these, it makes sense for us to do so as well.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>