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