Re: [5.0] Splitting authentication and authorization.

[Jeanfrancois Arcand]

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