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 2003/01/28 18:24:13 UTC
[5.0] Splitting authentication and authorization.
Hi,
since the last time I've proposed to split
Authentication/Authorization, we have moved to JMX Listerner as hooks
and standardize on JMX, I would like to re-open the discussion on
splitting the behaviour. Mainly, I would like to move three Realm
methods into an Authorizer interface and use the current Valve mechanism
as the first implementation.. The Authorizer will define:
public boolean
hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean
hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
public boolean hasRolePermission(HttpRequest,
HttpResponse,SecurityConstraint, String role);
I would like to see a clear distinction between Authorization and
Authentication. That will also allow third party implementation of JSR
115 (and the upcoming JSP on Authentication) to be more easily
implemented in Tomcat.
The first implementation will be a re-factoring of the current code.
Once completed, we should talk about having an JSR 115 implementation
(requires by default the Security Manager) or something customized for
Tomcat using JAAS.
The other solution is to move the Authenticator and Realm concept into
coyote as JMX listener and add the Autorizer logic there(will require a
CoyoteChain or something simliar to StandardPipeline). It is a major
refactoring and I cannot sign on a major task like that (but I can help
if we decide its the best decision). But I would favor a Valve for now
(the logic will be re-usable if we decide to move it into coyote).
That's what we call the two phases commit :-)
Throughts?
-- Jeanfrancois
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Splitting authentication and authorization.
Posted by Costin Manolache <cm...@yahoo.com>.
Jeanfrancois Arcand wrote:
>>If we look at JSR115, it sugests creating several (3?) permission objects
>>- each will be associated with the request.
>>
>>The creation of those objects will be part of the container ( probably in
>>a valve or other module ).
>>
>>The point is that all _authorization_ decisions will be deletated to
>>a plugin - tomcat will just make the calls. It will be tomcat's
>>job to provide the arguments and deal with the response.
>>
> OK. But I would prefer nmot having that code in the current
> AuthenticatorBase. We will need something inbetween AuthenticatorBase
> and AuthorizationBase (WebPermissionUtil)
As long as authorization (and authentication) does not deal directly with
http requests ( i.e. plain JSR115/Java security + JAAS ) - I'm fine.
Separating the authorization and authentication abstractions is one thing -
implementing the request processing is another. WebPermissionUtil needs
to know how to do the calls to authorization/authentication and how to
provide the right permissions.
I don't see too much value in having AuthenticatorBase and AuthorizatiorBase
- if the authorizer is a ProtectionDomain or Policy, all we need is an
implementation of that, called from the a valve.
>>I don't think mixing HTTP request processing in the authorizer is a good
>>idea, and it seems JSR115 ( at least the published draft ) is on the same
>>side.
>>
> Well, I agree...if we have something in between Authentication and
> Authorization :-)
That's the current valve - with the authorization code moved in a
TomcatProtectionDomain class ( that extends ProtectionDomain, is pluggable,
etc )
I would make the JAAS valve the default - and hope that Nacho and the
other people will be able to refactor the LDAP/JDBC valves to JAAS plugin
modules ( bonus: they'll become reusable in other servers that use JAAS ).
>>Another reason to let the authorizer deal with authorization and nothing
>>else. A false will mean "FORBIDDEN". ( we can still know what was
>>forbidden - we'll have to check 3 different permissions )\
>>
> True. Using the permission type we can find the which error type to
> return.
Or what action to perform - redirect to the login page, etc.
>>It seems JSR115 is a bit confused about this - in 4.7 it lists 6
>>alternatives for checking. I don't see why anything more than providing a
>>PermissionCollection and using impies() would be needed.
>>
>>But I'm fine with ProtectionDomain - it adds the CodeSource of the
>>context ( which is good ). Not sure what the principals would be.
>>
> The small problem I see is if we go with a PermissionCollection, people
> interested in extending the model will be limited by the
> PermissionCollection design. I would prefer having an implementation of
> a Policy object instead.
The problem with Policy:
" There is only one Policy object in effect at any given time " ( in
javadoc).
That limits a lot our flexibility.
Having a PermissionCollection per server or per Context still permits
people to have them in the global Policy.
Each Context will be associated with a CodeSource ( it is already AFAIK ),
and the Policy is just a container for CodeSource->PermissionCollection.
If we use PermissionCollection in our code, it is very easy
to extract it from a Policy ( if one is present ), but we can have more
flexibility. It would be possible to plug in a PermissionCollection
in a context - without having it in the Policy, and we can use tomcat
with a "foreign" policy, installed by a different application ( which may
not support 115 )
>>>Here is how I see the process (simplified):
>>>
>>>(1) when Tomcat starts, create the Policy (Provider is we standardize on
>>>115)
>>>
>>>
>>
>>There is no requirement on that - we can create a ProtectionDomain or
>>Policy without 115. ( well, we already do - AFAIK - for the class loader
>>).
>>
> Here I mean the Policy implementation.
See my previous comment.
I'm ok with having a Policy created - but as an optional step, our
code should use PermCollection. If a Policy already exists - and
it can be used ( i.e. 115 compatible ) - we should use it, but it
shouldn't be required.
( by JSR115 compatible I mean it support the interfaces that allow us
to modify it )
>>>(2) when deploying web.xml, created the appropriate Permission object
>>>(proprietary or 115) and store them inside a PolicyConfiguration object.
>>>
>>>
>>
>>That's my biggest problem with 115 :-)
>>
>>All J2EE is moving toward JMX - and they define yet another config API.
>>Sorry - I will vote for proprietary here ( actually - JMX ). The Policy
>>will just be an MBean ( of cource, that assummes JMX1.2 - so the mbean
>>server is protected ).
>>
> There is nothing that prevent us implementing a PolicyConfiguration
> using JMX and still be 115 compliant. Doing that will allow changing the
> permission without stopping the container. That's a very nice feature.
I know - my point was that JSR115 should specify the JMX attributes and
mechanism - instead of defining the interfaces.
Look at JSR77 for example ( which is far from perfect, but IMO goes in
a very good direction ).
>>Even if some base implementation in java are dependent on the
>>SecurityManager - we'll likely use our own Permission and Policy and
>>ProtectionDomain implementation, and that doesn't have to depend on SM.
>>
> Just fine.
>
> To summarize (trying to port my UML view using text :-) ), here is the
> way it will work:
>
> At Startup:
> - create the TomcatPolicyImpl
If one is not present - if tomcat is embeded in a J2EE server, most likely
one will be.
Or we just ignore the javadoc spec for Policy - which requires a single
Policy in effect.
> Deployment
> - generate all the permission
> - add them inside a JMXPolicyConfiguration
as a PolicyCollection, associated with the context
> - add the JMXPolicyConfiguration to TomcatPolicyImpl
or add the PolicyCollection to the Context, and use the
notifications to inform the policy mapper.
> Runtime
> - AuthenticatorBase: create the permission (here I wull recommend the
> delagation of the task to a WebPermissionUtil object)
> - AuthenticatorBase: call Authorization (which is TomcatPolicyImpl)
I don't like mixing the Authenticator with request processing either :-)
Let's call it SecurityValve - which will call the Authenticator for
authentication and Policy for authorization.
About Authenticator interface - that's either the current Realm ( with
authorization methods deprecated ), or we standardize on JAAS and
refactor the existing realms and user database to generic ( tomcat
independent !) JAAS plugins.
> Looks simple :-) What do you think?
I like it - I think it cleans a lot of things.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Splitting authentication and authorization.
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>Jeanfrancois Arcand wrote:
>
>
>
>>Where the permission object will be created? In Authenticator? I would
>>prefer delegating the permission to Authorization interface (but I can
>>live it :-) ). There is also another problem. If the permission is not
>>granted, the method will return false. Then we will need to set the
>>proper error message on the HttpServletResponse:
>>
>>
>
>If we look at JSR115, it sugests creating several (3?) permission objects -
>each will be associated with the request.
>
>The creation of those objects will be part of the container ( probably in
>a valve or other module ).
>
>The point is that all _authorization_ decisions will be deletated to
>a plugin - tomcat will just make the calls. It will be tomcat's
>job to provide the arguments and deal with the response.
>
OK. But I would prefer nmot having that code in the current
AuthenticatorBase. We will need something inbetween AuthenticatorBase
and AuthorizationBase (WebPermissionUtil)
>
>
>
>
>>((HttpServletResponse) response.getResponse()).sendError( .... )
>>
>>
>
>I don't think mixing HTTP request processing in the authorizer is a good
>idea, and it seems JSR115 ( at least the published draft ) is on the same
>side.
>
Well, I agree...if we have something in between Authentication and
Authorization :-)
>
>Let the authorizer deal with authorization - if the permissions
>( to a URI, method, transport ) are valid.
>
>
>
>
>>If the method only return false, then we will not be able to properly
>>set the error(SC_INTERNAL_SERVER_ERROR or FORBIDDEN etc.).
>>
>>
>
>Another reason to let the authorizer deal with authorization and nothing
>else. A false will mean "FORBIDDEN". ( we can still know what was forbidden
>- we'll have to check 3 different permissions )\
>
True. Using the permission type we can find the which error type to return.
>
>
>
>
>>I would prefer having:
>>
>>interface Authorization {
>> boolean hasPermission( HttpServletResponse, Permission p )
>>}
>>
>>
>
>You can get the Response from the Request - passing one or both is the same.
>
True. My mistake.
>
>Again - that would mean the authorizer will deal with HTTP processing, that
>will keep code complex.
>
>The JSR115 aproach is IMO much better - all the information that must be
>checked ( URI, method, etc ) is passed as part of the requested permission.
>
>
>
>
>>since p should contains all the information required to grant/denied the
>>request.
>>
>>
>
>Exactly - there is no need to pass the response/request. If you really want
>- you can cast the permission to TomcatRequestPermission and get the source
>request and response.
>
+1
>
>
>
>
>
>
>>or
>>
>>interface Authorization {
>> boolean hasPermission( HttpServletRequest, HttpServletResponse, String
>> role )
>>}
>>
>>if we don't want a Permission object.
>>
>>
>
>I don't see why not. ( and it's not one, but few ). This is far more
>flexible.
>
>
>
>
>>Based on the permission type, we will be able to discover if it's a
>>Resource/UserData/Role call.
>>
>>
>
>+1
>
>
>
>
>>>I'm still trying to figure out the hack in JSR155 ( with the
>>>permission per request ) - but if you understand
>>>
>>>
>>>
>>I hope I understand a little...I did participate in the
>>definition/implementation of the specs :-)
>>
>>
>
>Good to know :-)
>
>
>
>
>
>>>it we can even
>>>use
>>>
>>> boolean implies( Permission currentRequestPermission,
>>> Permission targetPermission )
>>>
>>>
>>>
>>Here I assume targetPermission is a permission that we have created when
>>reading the web.xml (right?). We will have a collection of
>>targetPermission. To make it work, we will have to do:
>>
>>
>
>Sorry - I meant PermissionCollection for the second argument, and yes - it
>includes all the permissions from the web.xml ( and maybe the permissions
>from the policy - if in sandbox mode ).
>
>
>
>
>
>>for (int i; i < targetPermissionCollection; i++){
>> ...implies(currentRequestPermission, targetPermissionCollection(i));
>>}
>>
>>I would prefer having:
>>
>>Provider
>>----------
>>
>>boolean implies( ProtectionDomain currentRequestPermission,
>> Permission currentRequestPermission )
>>
>>
>
>Yes, that's what I had in mind too - except PermissionCollection instead
>of ProtectionDomain.
>
>
>Actually - I have a better idea ( IMHO :-):
>
>Request {
> ...
> Permissions requestPermissions[]; <- we add this to coyote request ( with
> getter/setter )
>}
>
>Context {
> ....
> PermissionCollection authorizer;
>}
>
>The "Authorizer" will just be an implementation of PermissionCollection.
>
>It seems JSR115 is a bit confused about this - in 4.7 it lists 6
>alternatives for checking. I don't see why anything more than providing a
>PermissionCollection and using impies() would be needed.
>
>But I'm fine with ProtectionDomain - it adds the CodeSource of the
>context ( which is good ). Not sure what the principals would be.
>
The small problem I see is if we go with a PermissionCollection, people
interested in extending the model will be limited by the
PermissionCollection design. I would prefer having an implementation of
a Policy object instead.
>
>
>
>
>
>
>>Here is how I see the process (simplified):
>>
>>(1) when Tomcat starts, create the Policy (Provider is we standardize on
>>115)
>>
>>
>
>There is no requirement on that - we can create a ProtectionDomain or
>Policy without 115. ( well, we already do - AFAIK - for the class loader ).
>
Here I mean the Policy implementation.
>
>
>
>>(2) when deploying web.xml, created the appropriate Permission object
>>(proprietary or 115) and store them inside a PolicyConfiguration object.
>>
>>
>
>That's my biggest problem with 115 :-)
>
>All J2EE is moving toward JMX - and they define yet another config API.
>Sorry - I will vote for proprietary here ( actually - JMX ). The Policy
>will just be an MBean ( of cource, that assummes JMX1.2 - so the mbean
>server is protected ).
>
There is nothing that prevent us implementing a PolicyConfiguration
using JMX and still be 115 compliant. Doing that will allow changing the
permission without stopping the container. That's a very nice feature.
>
>
>
>
>
>>(3) each PolicyConfiguration will be stored in the Policy
>>
>>
>
>Big +1 - if you mean the global Policy will have the Permission info
>for all contexts.
>
>That's a very good thing - having a single global Policy ( and
>a single global mapper :-)
>
>
>
>
>>(4) during a
>>request, AuthenticatorBase will 4.1 create a Permission object
>>4.2 invoke Authorization.hasPermission()
>>4.3 invoke the Policy.implies()
>>4.4 Based on the ProtectionDomain, the Policy will locate the proper
>>PolicyConfiguration, get the permission collection and do a
>>PermissionCollection.implies(currentRequestPermission).
>>
>>
>
>You mean 4.4 is a part of the implementation details of the Policy I hope ?
>
>AuthenticatorBase will need to create a number of Permission objects - if we
>want to stay in type/path/actions and not use an extended Permission.
>This will also allow to provide the right response codes.
>
>This needs more review - but it sounds good.
>
>There are few tricks - do we perform authentication before or only if
>needed? We'll have to try again after authentication - at least for
>role-related permissions.
>
I think we will discover case where we don't need to call the Policy class.
>
>
>
>
>>This way the Autorization implementation doesn't have to know anything
>>about web.xml permission.
>>
>>
>
>+1
>
>Or about the Request and Response :-)
>
>
>
>
>>The bigest problem is when we create the permission (at deployment time).
>>We have to use the url pattern matching rule to creates all the possible
>>permissions. Performance staregy will be required here (I will buy Remy's
>>book :-) )
>>
>>
>
>This is exactly the same problem that the request Mapper resolves. In the
>global Policy we store full urls - and the Mapper ( hopefully the same code
>that does request mapping ) will do the job.
>
>Internally Policy can optimize the data structure - or use some info from
>the request mapping ( if the request and auth mappers know about each
>other).
>
+1
>
>
>
>>>BTW, in the draft I'm reading there is also the option of using
>>>Policy ( which would not require the security manager ).
>>>
>>>
>>>
>>My understanding was that the security manager and permissions are one.
>>I like the idea of using the Policy without the Security Manager. I will
>>read a little on the subject....
>>
>>
>
>The security manager requires permissions - of course.
>
>Permissions don't require security manager. It is just an optimization
>people make to avoid checking permissions ( i.e. don't check if no security
>manager is started ).
>
>Even if some base implementation in java are dependent on the
>SecurityManager - we'll likely use our own Permission and Policy and
>ProtectionDomain implementation, and that doesn't have to depend on SM.
>
Just fine.
To summarize (trying to port my UML view using text :-) ), here is the
way it will work:
At Startup:
- create the TomcatPolicyImpl
Deployment
- generate all the permission
- add them inside a JMXPolicyConfiguration
- add the JMXPolicyConfiguration to TomcatPolicyImpl
Runtime
- AuthenticatorBase: create the permission (here I wull recommend the
delagation of the task to a WebPermissionUtil object)
- AuthenticatorBase: call Authorization (which is TomcatPolicyImpl)
Looks simple :-) What do you think?
-- Jeanfrancois
>
>Costin
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
Re: [5.0] Splitting authentication and authorization.
Posted by Costin Manolache <cm...@yahoo.com>.
Jeanfrancois Arcand wrote:
> Where the permission object will be created? In Authenticator? I would
> prefer delegating the permission to Authorization interface (but I can
> live it :-) ). There is also another problem. If the permission is not
> granted, the method will return false. Then we will need to set the
> proper error message on the HttpServletResponse:
If we look at JSR115, it sugests creating several (3?) permission objects -
each will be associated with the request.
The creation of those objects will be part of the container ( probably in
a valve or other module ).
The point is that all _authorization_ decisions will be deletated to
a plugin - tomcat will just make the calls. It will be tomcat's
job to provide the arguments and deal with the response.
> ((HttpServletResponse) response.getResponse()).sendError( .... )
I don't think mixing HTTP request processing in the authorizer is a good
idea, and it seems JSR115 ( at least the published draft ) is on the same
side.
Let the authorizer deal with authorization - if the permissions
( to a URI, method, transport ) are valid.
> If the method only return false, then we will not be able to properly
> set the error(SC_INTERNAL_SERVER_ERROR or FORBIDDEN etc.).
Another reason to let the authorizer deal with authorization and nothing
else. A false will mean "FORBIDDEN". ( we can still know what was forbidden
- we'll have to check 3 different permissions )
> I would prefer having:
>
> interface Authorization {
> boolean hasPermission( HttpServletResponse, Permission p )
> }
You can get the Response from the Request - passing one or both is the same.
Again - that would mean the authorizer will deal with HTTP processing, that
will keep code complex.
The JSR115 aproach is IMO much better - all the information that must be
checked ( URI, method, etc ) is passed as part of the requested permission.
> since p should contains all the information required to grant/denied the
> request.
Exactly - there is no need to pass the response/request. If you really want
- you can cast the permission to TomcatRequestPermission and get the source
request and response.
> or
>
> interface Authorization {
> boolean hasPermission( HttpServletRequest, HttpServletResponse, String
> role )
> }
>
> if we don't want a Permission object.
I don't see why not. ( and it's not one, but few ). This is far more
flexible.
> Based on the permission type, we will be able to discover if it's a
> Resource/UserData/Role call.
+1
>>I'm still trying to figure out the hack in JSR155 ( with the
>>permission per request ) - but if you understand
>>
> I hope I understand a little...I did participate in the
> definition/implementation of the specs :-)
Good to know :-)
>> it we can even
>>use
>>
>> boolean implies( Permission currentRequestPermission,
>> Permission targetPermission )
>>
> Here I assume targetPermission is a permission that we have created when
> reading the web.xml (right?). We will have a collection of
> targetPermission. To make it work, we will have to do:
Sorry - I meant PermissionCollection for the second argument, and yes - it
includes all the permissions from the web.xml ( and maybe the permissions
from the policy - if in sandbox mode ).
> for (int i; i < targetPermissionCollection; i++){
> ...implies(currentRequestPermission, targetPermissionCollection(i));
> }
>
> I would prefer having:
>
> Provider
> ----------
>
> boolean implies( ProtectionDomain currentRequestPermission,
> Permission currentRequestPermission )
Yes, that's what I had in mind too - except PermissionCollection instead
of ProtectionDomain.
Actually - I have a better idea ( IMHO :-):
Request {
...
Permissions requestPermissions[]; <- we add this to coyote request ( with
getter/setter )
}
Context {
....
PermissionCollection authorizer;
}
The "Authorizer" will just be an implementation of PermissionCollection.
It seems JSR115 is a bit confused about this - in 4.7 it lists 6
alternatives for checking. I don't see why anything more than providing a
PermissionCollection and using impies() would be needed.
But I'm fine with ProtectionDomain - it adds the CodeSource of the
context ( which is good ). Not sure what the principals would be.
> Here is how I see the process (simplified):
>
> (1) when Tomcat starts, create the Policy (Provider is we standardize on
> 115)
There is no requirement on that - we can create a ProtectionDomain or
Policy without 115. ( well, we already do - AFAIK - for the class loader ).
> (2) when deploying web.xml, created the appropriate Permission object
> (proprietary or 115) and store them inside a PolicyConfiguration object.
That's my biggest problem with 115 :-)
All J2EE is moving toward JMX - and they define yet another config API.
Sorry - I will vote for proprietary here ( actually - JMX ). The Policy
will just be an MBean ( of cource, that assummes JMX1.2 - so the mbean
server is protected ).
> (3) each PolicyConfiguration will be stored in the Policy
Big +1 - if you mean the global Policy will have the Permission info
for all contexts.
That's a very good thing - having a single global Policy ( and
a single global mapper :-)
> (4) during a
> request, AuthenticatorBase will 4.1 create a Permission object
> 4.2 invoke Authorization.hasPermission()
> 4.3 invoke the Policy.implies()
> 4.4 Based on the ProtectionDomain, the Policy will locate the proper
> PolicyConfiguration, get the permission collection and do a
> PermissionCollection.implies(currentRequestPermission).
You mean 4.4 is a part of the implementation details of the Policy I hope ?
AuthenticatorBase will need to create a number of Permission objects - if we
want to stay in type/path/actions and not use an extended Permission.
This will also allow to provide the right response codes.
This needs more review - but it sounds good.
There are few tricks - do we perform authentication before or only if
needed? We'll have to try again after authentication - at least for
role-related permissions.
> This way the Autorization implementation doesn't have to know anything
> about web.xml permission.
+1
Or about the Request and Response :-)
> The bigest problem is when we create the permission (at deployment time).
> We have to use the url pattern matching rule to creates all the possible
> permissions. Performance staregy will be required here (I will buy Remy's
> book :-) )
This is exactly the same problem that the request Mapper resolves. In the
global Policy we store full urls - and the Mapper ( hopefully the same code
that does request mapping ) will do the job.
Internally Policy can optimize the data structure - or use some info from
the request mapping ( if the request and auth mappers know about each
other).
>> BTW, in the draft I'm reading there is also the option of using
>>Policy ( which would not require the security manager ).
>>
> My understanding was that the security manager and permissions are one.
> I like the idea of using the Policy without the Security Manager. I will
> read a little on the subject....
The security manager requires permissions - of course.
Permissions don't require security manager. It is just an optimization
people make to avoid checking permissions ( i.e. don't check if no security
manager is started ).
Even if some base implementation in java are dependent on the
SecurityManager - we'll likely use our own Permission and Policy and
ProtectionDomain implementation, and that doesn't have to depend on SM.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Splitting authentication and authorization.
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>What about this:
>
>instead of 3 methods, have a single method:
>
>interface Authorization {
> boolean hasPermission( HttpServletRequest, Permission perm )
>}
>
115, not 155 :-)
Where the permission object will be created? In Authenticator? I would
prefer delegating the permission to Authorization interface (but I can
live it :-) ). There is also another problem. If the permission is not
granted, the method will return false. Then we will need to set the
proper error message on the HttpServletResponse:
((HttpServletResponse) response.getResponse()).sendError( .... )
If the method only return false, then we will not be able to properly
set the error(SC_INTERNAL_SERVER_ERROR or FORBIDDEN etc.).
I would prefer having:
interface Authorization {
boolean hasPermission( HttpServletResponse, Permission p )
}
since p should contains all the information required to grant/denied the request.
or
interface Authorization {
boolean hasPermission( HttpServletRequest, HttpServletResponse, String role )
}
if we don't want a Permission object.
Based on the permission type, we will be able to discover if it's a
Resource/UserData/Role call.
>
>I'm still trying to figure out the hack in JSR155 ( with the
>permission per request ) - but if you understand
>
I hope I understand a little...I did participate in the
definition/implementation of the specs :-)
> it we can even
>use
>
> boolean implies( Permission currentRequestPermission,
> Permission targetPermission )
>
Here I assume targetPermission is a permission that we have created when
reading the web.xml (right?). We will have a collection of
targetPermission. To make it work, we will have to do:
for (int i; i < targetPermissionCollection; i++){
...implies(currentRequestPermission, targetPermissionCollection(i));
}
I would prefer having:
Provider
----------
boolean implies( ProtectionDomain currentRequestPermission,
Permission currentRequestPermission )
Here is how I see the process (simplified):
(1) when Tomcat starts, create the Policy (Provider is we standardize on 115)
(2) when deploying web.xml, created the appropriate Permission object (proprietary or 115) and store them inside a PolicyConfiguration object.
(3) each PolicyConfiguration will be stored in the Policy
(4) during a request, AuthenticatorBase will
4.1 create a Permission object
4.2 invoke Authorization.hasPermission()
4.3 invoke the Policy.implies()
4.4 Based on the ProtectionDomain, the Policy will locate the proper PolicyConfiguration, get the permission collection and do a PermissionCollection.implies(currentRequestPermission).
This way the Autorization implementation doesn't have to know anything about web.xml permission.
The bigest problem is when we create the permission (at deployment time). We have to use the url pattern matching rule to creates all the possible permissions. Performance staregy will be required here (I will buy Remy's book :-) )
>
>Where currentRequestPermission will hold info about the request.
>
>When we decide to support JSR155 - we can either make our Permission
>implement the JSR155 classes, or change the code to support both
>kinds of Permissions.
>Even if we support 155 - we'll still need our own implementation -
>for optimizations, recycle, etc.
>
>It seems Authorization interface is needed - at least from reading
>155. BTW, in the draft I'm reading there is also the option of using
>Policy ( which would not require the security manager ).
>
My understanding was that the security manager and permissions are one.
I like the idea of using the Policy without the Security Manager. I will
read a little on the subject....
-- Jeanfrancois
>
>Costin
>
>
>Costin Manolache wrote:
>
>
>
>>It seems I missread your post, I tought you would add another
>>authentication interface too ...
>>
>>But I still don't like the interface :-)
>>
>>I need to think about it.
>>
>>I'm pretty sure we can use Policy, Permission, etc without a security
>>manager, and it would be better to go directly to use those.
>>
>>One problem is in parameter passing ( since HttpServletRequest and
>>all other info must be available when making the policy decission ).
>>
>>The authentication layer should be able to return a Principal
>>that is associated with the request. And the authorization layer shouldn't
>>care about the request - only about the Principal and the required
>>permission.
>>
>>In other words - all security constraints can be converted to Permissions
>>( no need for 3 methods in the interface - just one method that checks
>>a particular Permission ).
>>
>>The problem mentioned about JBoss is due to the fact that the
>>authorization layer calls the authentication ( this seems to be the case
>>in your proposal as well ). A request that doesn't have a security
>>constraint will not try to set the Principal.
>>
>>Costin
>>
>>
>>
>>
>>>since the last time I've proposed to split
>>>Authentication/Authorization, we have moved to JMX Listerner as hooks
>>>and standardize on JMX, I would like to re-open the discussion on
>>>splitting the behaviour. Mainly, I would like to move three Realm
>>>methods into an Authorizer interface and use the current Valve mechanism
>>>as the first implementation.. The Authorizer will define:
>>>
>>>public boolean
>>>hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
>>>public boolean
>>>hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
>>>public boolean hasRolePermission(HttpRequest,
>>>HttpResponse,SecurityConstraint, String role);
>>>
>>>I would like to see a clear distinction between Authorization and
>>>Authentication. That will also allow third party implementation of JSR
>>>115 (and the upcoming JSP on Authentication) to be more easily
>>>implemented in Tomcat.
>>>
>>>The first implementation will be a re-factoring of the current code.
>>>Once completed, we should talk about having an JSR 115 implementation
>>>(requires by default the Security Manager) or something customized for
>>>Tomcat using JAAS.
>>>
>>>The other solution is to move the Authenticator and Realm concept into
>>>coyote as JMX listener and add the Autorizer logic there(will require a
>>>CoyoteChain or something simliar to StandardPipeline). It is a major
>>>refactoring and I cannot sign on a major task like that (but I can help
>>>if we decide its the best decision). But I would favor a Valve for now
>>>(the logic will be re-usable if we decide to move it into coyote).
>>>That's what we call the two phases commit :-)
>>>
>>>Throughts?
>>>
>>>-- Jeanfrancois
>>>
>>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
Re: [5.0] Splitting authentication and authorization.
Posted by Costin Manolache <cm...@yahoo.com>.
What about this:
instead of 3 methods, have a single method:
interface Authorization {
boolean hasPermission( HttpServletRequest, Permission perm )
}
I'm still trying to figure out the hack in JSR155 ( with the
permission per request ) - but if you understand it we can even
use
boolean implies( Permission currentRequestPermission,
Permission targetPermission )
Where currentRequestPermission will hold info about the request.
When we decide to support JSR155 - we can either make our Permission
implement the JSR155 classes, or change the code to support both
kinds of Permissions.
Even if we support 155 - we'll still need our own implementation -
for optimizations, recycle, etc.
It seems Authorization interface is needed - at least from reading
155. BTW, in the draft I'm reading there is also the option of using
Policy ( which would not require the security manager ).
Costin
Costin Manolache wrote:
> It seems I missread your post, I tought you would add another
> authentication interface too ...
>
> But I still don't like the interface :-)
>
> I need to think about it.
>
> I'm pretty sure we can use Policy, Permission, etc without a security
> manager, and it would be better to go directly to use those.
>
> One problem is in parameter passing ( since HttpServletRequest and
> all other info must be available when making the policy decission ).
>
> The authentication layer should be able to return a Principal
> that is associated with the request. And the authorization layer shouldn't
> care about the request - only about the Principal and the required
> permission.
>
> In other words - all security constraints can be converted to Permissions
> ( no need for 3 methods in the interface - just one method that checks
> a particular Permission ).
>
> The problem mentioned about JBoss is due to the fact that the
> authorization layer calls the authentication ( this seems to be the case
> in your proposal as well ). A request that doesn't have a security
> constraint will not try to set the Principal.
>
> Costin
>
>
>> since the last time I've proposed to split
>> Authentication/Authorization, we have moved to JMX Listerner as hooks
>> and standardize on JMX, I would like to re-open the discussion on
>> splitting the behaviour. Mainly, I would like to move three Realm
>> methods into an Authorizer interface and use the current Valve mechanism
>> as the first implementation.. The Authorizer will define:
>>
>> public boolean
>> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
>> public boolean
>> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
>> public boolean hasRolePermission(HttpRequest,
>> HttpResponse,SecurityConstraint, String role);
>>
>> I would like to see a clear distinction between Authorization and
>> Authentication. That will also allow third party implementation of JSR
>> 115 (and the upcoming JSP on Authentication) to be more easily
>> implemented in Tomcat.
>>
>> The first implementation will be a re-factoring of the current code.
>> Once completed, we should talk about having an JSR 115 implementation
>> (requires by default the Security Manager) or something customized for
>> Tomcat using JAAS.
>>
>> The other solution is to move the Authenticator and Realm concept into
>> coyote as JMX listener and add the Autorizer logic there(will require a
>> CoyoteChain or something simliar to StandardPipeline). It is a major
>> refactoring and I cannot sign on a major task like that (but I can help
>> if we decide its the best decision). But I would favor a Valve for now
>> (the logic will be re-usable if we decide to move it into coyote).
>> That's what we call the two phases commit :-)
>>
>> Throughts?
>>
>> -- Jeanfrancois
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Splitting authentication and authorization.
Posted by Costin Manolache <cm...@yahoo.com>.
It seems I missread your post, I tought you would add another
authentication interface too ...
But I still don't like the interface :-)
I need to think about it.
I'm pretty sure we can use Policy, Permission, etc without a security
manager, and it would be better to go directly to use those.
One problem is in parameter passing ( since HttpServletRequest and
all other info must be available when making the policy decission ).
The authentication layer should be able to return a Principal
that is associated with the request. And the authorization layer shouldn't
care about the request - only about the Principal and the required
permission.
In other words - all security constraints can be converted to Permissions
( no need for 3 methods in the interface - just one method that checks
a particular Permission ).
The problem mentioned about JBoss is due to the fact that the authorization
layer calls the authentication ( this seems to be the case in your proposal
as well ). A request that doesn't have a security constraint will not try
to set the Principal.
Costin
> since the last time I've proposed to split
> Authentication/Authorization, we have moved to JMX Listerner as hooks
> and standardize on JMX, I would like to re-open the discussion on
> splitting the behaviour. Mainly, I would like to move three Realm
> methods into an Authorizer interface and use the current Valve mechanism
> as the first implementation.. The Authorizer will define:
>
> public boolean
> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean
> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean hasRolePermission(HttpRequest,
> HttpResponse,SecurityConstraint, String role);
>
> I would like to see a clear distinction between Authorization and
> Authentication. That will also allow third party implementation of JSR
> 115 (and the upcoming JSP on Authentication) to be more easily
> implemented in Tomcat.
>
> The first implementation will be a re-factoring of the current code.
> Once completed, we should talk about having an JSR 115 implementation
> (requires by default the Security Manager) or something customized for
> Tomcat using JAAS.
>
> The other solution is to move the Authenticator and Realm concept into
> coyote as JMX listener and add the Autorizer logic there(will require a
> CoyoteChain or something simliar to StandardPipeline). It is a major
> refactoring and I cannot sign on a major task like that (but I can help
> if we decide its the best decision). But I would favor a Valve for now
> (the logic will be re-usable if we decide to move it into coyote).
> That's what we call the two phases commit :-)
>
> Throughts?
>
> -- Jeanfrancois
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Splitting authentication and authorization.
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>Jeanfrancois Arcand wrote:
>
>
>
>>Costin Manolache wrote:
>>
>>
>>
>>>Wouldn't be better to just standardize on JAAS for authentication
>>>and stop using our own private interfaces ?
>>>AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
>>>
>>>
>>>
>>I agree on JAAS too for Authentication if it is available for the
>>majority of open source VM I will first refactor the interface, commit
>>them and then start working on JAAS if everybody agree.
>>
>>
>
>AFAIK it is available- haven't checked it. Even if it isn't - I hope there
>is still a standalone download that can be used with any VM ( like JDK1.2 ).
>
>
>
>
>>>The only problem is getUserRoles(), which is not supported very well
>>>by JAAS.
>>>
>>>I'm fine with implementing them as valves - I'm not sure the interface
>>>you're proposing is the best choice.
>>>
>>>
>>>
>>Why? To be able to authorize properly, we need at least the Principal
>>and the resource (+ the SecurityConstraint from the web.xml).
>>
>>
>
>We already have _far_ too many interfaces ( and base classes, abstract
>classes, and so on ).
>
Not sure I agree. We cannot have 1 interface for everything (Yes we can,
but we will have to rebuild a lot of things). And having Base classes
and Interface let the design very open. But that's not the goal of the
discussion :-)
>Do you expect people to implement this new interface ( instead of JAAS ) ?
>
Yes. JAAS should be used by default, but if someone doesn't want to use
it, he can switch to the current implementation. The servlet spec
doesn't requires JAAS for enforcing the web.xml security element..
>As long as a clear standard interface exists ( JAAS ) and we know that it
>can be used ( there is a JAAS plugin for tomcat ) - I see no reason to
>create yet another interface.
>
Remember that JAAS is *not enough* for authorization (that's why JSR 115
was defined). 115 is one layer on top of JAAS (uses JAAS) We should not
re-invent something (even with JAAS) but use a known api. In order to do
that, we need to be able, at authorization time, to call the Policy.
Right now, this will happen:
AuthenticatorBase -> RealmBase.hasResourcePermission()
instead,as a first step, I recommend
AuthenticatorBase -> AuthorizerBase.hasResourcePermission()
If I follow you properly, you want:
AuthenticatorBase -> TomcatPolicy
The problem is some pre-processing code will have to reside inside
Autheticator if we do that like this. That's the reason the logic should
be delegated to Authorizer (who will call the TomcatPolicy).
Again. I do not want to remove the Valve behaviour for now. And do not
push JSR 115 also (we should vote on JAAS/115). The current
implementation is fast and doesn't requires the Security Manager.
115/JAAS implementation will be slower, for sure (download J2EE 1.4 RI
beta and do a test with the same web app. You will visually see my point
:-) ). 115 PFD2 has been modified and I'm sure the performance hit will
be improved.
>
>Are you going to port LDAP, JAAS, database plugins as well as UserDatabase
>to the new interface ?
>
That will be easy because authorization methods (hasResourcePermissions,
hasUserDataPermission and hasRole) were private before Tomcat 5. I've
moved them to RealmBase in late august (if I remember correctly). Those
components were not affected. The logic for those methods are guided by
the Servlet specs, so I don't see why we should implement it using LDAP
or JAAS. 115 could be a viable solution if people agree.
>Just refactoring the interface and increasing the mess with 33% is not good.
>( 33% - because we already have 2 interfaces for this, Realm and
>UserDatabase )
>
Realy, you think it is a mess? Be positive, nothing perfect :-)
>
>
>
>
>
>>>I would be +1 on using the Policy for authorization - my understanding is
>>>that it _does_not_ require the security manager to be enabled.
>>>
>>>
>>>
>>I'm not sure about that. My understanding was that when you call
>>AccessController.checkPermission (that require the Security Manager to
>>be turned on), the class will delegate the call to Policy.implies
>>implementation. If we don't have the security manager enabled, that
>>means we use Policy.implies only. Where did you get the information?
>>
>>
>
>Why would we call AccessController.checkPermission ????
>
Just to be consistent with JAAS. I never see a case where JAAS was used
without the Security Manager. IMBW.
>
>The information about the access control is stored in a PolicyObject.
>If the base implementation requires the security manager ( and I doubt )- we
>can use our own implementation of Policy. We'll have to use our own anyway
>for performance optimizations.
>
>At least from the javadoc of Policy and my understanding of java security -
>I can't see any good reason why Policy would require a security manager
>( except the fact that this is how most people use it today ).
>
Will see. I don't like implementing part of an api, but I understand
your point.
-- Jeanfrancois
>
>
>Costin
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: [5.0] Splitting authentication and authorization.
Posted by Costin Manolache <cm...@yahoo.com>.
Jeanfrancois Arcand wrote:
> Costin Manolache wrote:
>
>>Wouldn't be better to just standardize on JAAS for authentication
>>and stop using our own private interfaces ?
>>AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
>>
> I agree on JAAS too for Authentication if it is available for the
> majority of open source VM I will first refactor the interface, commit
> them and then start working on JAAS if everybody agree.
AFAIK it is available- haven't checked it. Even if it isn't - I hope there
is still a standalone download that can be used with any VM ( like JDK1.2 ).
>>The only problem is getUserRoles(), which is not supported very well
>>by JAAS.
>>
>>I'm fine with implementing them as valves - I'm not sure the interface
>>you're proposing is the best choice.
>>
> Why? To be able to authorize properly, we need at least the Principal
> and the resource (+ the SecurityConstraint from the web.xml).
We already have _far_ too many interfaces ( and base classes, abstract
classes, and so on ).
Do you expect people to implement this new interface ( instead of JAAS ) ?
As long as a clear standard interface exists ( JAAS ) and we know that it
can be used ( there is a JAAS plugin for tomcat ) - I see no reason to
create yet another interface.
Are you going to port LDAP, JAAS, database plugins as well as UserDatabase
to the new interface ?
Just refactoring the interface and increasing the mess with 33% is not good.
( 33% - because we already have 2 interfaces for this, Realm and
UserDatabase )
>>I would be +1 on using the Policy for authorization - my understanding is
>>that it _does_not_ require the security manager to be enabled.
>>
> I'm not sure about that. My understanding was that when you call
> AccessController.checkPermission (that require the Security Manager to
> be turned on), the class will delegate the call to Policy.implies
> implementation. If we don't have the security manager enabled, that
> means we use Policy.implies only. Where did you get the information?
Why would we call AccessController.checkPermission ????
The information about the access control is stored in a PolicyObject.
If the base implementation requires the security manager ( and I doubt )- we
can use our own implementation of Policy. We'll have to use our own anyway
for performance optimizations.
At least from the javadoc of Policy and my understanding of java security -
I can't see any good reason why Policy would require a security manager
( except the fact that this is how most people use it today ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Splitting authentication and authorization.
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>Wouldn't be better to just standardize on JAAS for authentication
>and stop using our own private interfaces ?
>AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
>
I agree on JAAS too for Authentication if it is available for the
majority of open source VM I will first refactor the interface, commit
them and then start working on JAAS if everybody agree.
>
>The only problem is getUserRoles(), which is not supported very well
>by JAAS.
>
>I'm fine with implementing them as valves - I'm not sure the interface
>you're proposing is the best choice.
>
Why? To be able to authorize properly, we need at least the Principal
and the resource (+ the SecurityConstraint from the web.xml).
>
>+1 on spliting between Authorization and Authentication _and_ user
>management ( the user database ).
>
>I would preffer doing the "right" thing - and using existing standards
>APIs where it is possible - JAAS for authentication is pretty clear.
>
>I would be +1 on using the Policy for authorization - my understanding is
>that it _does_not_ require the security manager to be enabled.
>
I'm not sure about that. My understanding was that when you call
AccessController.checkPermission (that require the Security Manager to
be turned on), the class will delegate the call to Policy.implies
implementation. If we don't have the security manager enabled, that
means we use Policy.implies only. Where did you get the information?
> All the code
>I've seen is checking for a security manager - because the contract is that
>without a secuirty manager you shouldn't enforce the policy. However the
>Policy object ( or some implementation ) should just work without the SM.
>
I'm fine with the idea if we can come up with something that has the
same behaviour with a SecurityManager. When running under the security
manager, we should be 115 compliant.
>
>Regarding use of JMX - well, JMX should be used to enable management of
>whatever authenticator/authorizer module we use ( attributes, runtime info,
>etc ). We should use JMX notification for callbacks - but only when a
>standard API doesn't exists ( or if the standard is too bad or unusable ).
>
-- Jeanfrancois
>
>Costin
>
>Jeanfrancois Arcand wrote:
>
>
>
>>Hi,
>>
>>since the last time I've proposed to split
>>Authentication/Authorization, we have moved to JMX Listerner as hooks
>>and standardize on JMX, I would like to re-open the discussion on
>>splitting the behaviour. Mainly, I would like to move three Realm
>>methods into an Authorizer interface and use the current Valve mechanism
>>as the first implementation.. The Authorizer will define:
>>
>>public boolean
>>hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
>>public boolean
>>hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
>>public boolean hasRolePermission(HttpRequest,
>>HttpResponse,SecurityConstraint, String role);
>>
>>I would like to see a clear distinction between Authorization and
>>Authentication. That will also allow third party implementation of JSR
>>115 (and the upcoming JSP on Authentication) to be more easily
>>implemented in Tomcat.
>>
>>The first implementation will be a re-factoring of the current code.
>>Once completed, we should talk about having an JSR 115 implementation
>>(requires by default the Security Manager) or something customized for
>>Tomcat using JAAS.
>>
>>The other solution is to move the Authenticator and Realm concept into
>>coyote as JMX listener and add the Autorizer logic there(will require a
>>CoyoteChain or something simliar to StandardPipeline). It is a major
>>refactoring and I cannot sign on a major task like that (but I can help
>>if we decide its the best decision). But I would favor a Valve for now
>>(the logic will be re-usable if we decide to move it into coyote).
>>That's what we call the two phases commit :-)
>>
>>Throughts?
>>
>>-- Jeanfrancois
>>
>>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: [5.0] Splitting authentication and authorization.
Posted by Costin Manolache <cm...@yahoo.com>.
Wouldn't be better to just standardize on JAAS for authentication
and stop using our own private interfaces ?
AFAIK JAAS is included in JDK1.3+ - and available to older VMs.
The only problem is getUserRoles(), which is not supported very well
by JAAS.
I'm fine with implementing them as valves - I'm not sure the interface
you're proposing is the best choice.
+1 on spliting between Authorization and Authentication _and_ user
management ( the user database ).
I would preffer doing the "right" thing - and using existing standards
APIs where it is possible - JAAS for authentication is pretty clear.
I would be +1 on using the Policy for authorization - my understanding is
that it _does_not_ require the security manager to be enabled. All the code
I've seen is checking for a security manager - because the contract is that
without a secuirty manager you shouldn't enforce the policy. However the
Policy object ( or some implementation ) should just work without the SM.
Regarding use of JMX - well, JMX should be used to enable management of
whatever authenticator/authorizer module we use ( attributes, runtime info,
etc ). We should use JMX notification for callbacks - but only when a
standard API doesn't exists ( or if the standard is too bad or unusable ).
Costin
Jeanfrancois Arcand wrote:
> Hi,
>
> since the last time I've proposed to split
> Authentication/Authorization, we have moved to JMX Listerner as hooks
> and standardize on JMX, I would like to re-open the discussion on
> splitting the behaviour. Mainly, I would like to move three Realm
> methods into an Authorizer interface and use the current Valve mechanism
> as the first implementation.. The Authorizer will define:
>
> public boolean
> hasResourcePermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean
> hasUserDataPermission(HttpRequest,HttpResponse,SecurityConstraint);
> public boolean hasRolePermission(HttpRequest,
> HttpResponse,SecurityConstraint, String role);
>
> I would like to see a clear distinction between Authorization and
> Authentication. That will also allow third party implementation of JSR
> 115 (and the upcoming JSP on Authentication) to be more easily
> implemented in Tomcat.
>
> The first implementation will be a re-factoring of the current code.
> Once completed, we should talk about having an JSR 115 implementation
> (requires by default the Security Manager) or something customized for
> Tomcat using JAAS.
>
> The other solution is to move the Authenticator and Realm concept into
> coyote as JMX listener and add the Autorizer logic there(will require a
> CoyoteChain or something simliar to StandardPipeline). It is a major
> refactoring and I cannot sign on a major task like that (but I can help
> if we decide its the best decision). But I would favor a Valve for now
> (the logic will be re-usable if we decide to move it into coyote).
> That's what we call the two phases commit :-)
>
> Throughts?
>
> -- Jeanfrancois
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>