Costin Manolache wrote:
What about this:115, not 155 :-)
instead of 3 methods, have a single method:
interface Authorization {
boolean hasPermission( HttpServletRequest, Permission perm )
}
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 hope I understand a little...I did participate in the definition/implementation of the specs :-)
I'm still trying to figure out the hack in JSR155 ( with the permission per request ) - but if you understand
it we can evenHere 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:
use
boolean implies( Permission currentRequestPermission, Permission targetPermission )
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 :-) )
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....
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 ).
-- 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
