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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
