Re: [5.0] Splitting authentication and authorization.

[Jeanfrancois Arcand]

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