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.
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).
+1 on spliting between Authorization and Authentication _and_ user
management ( the user database ).
I would preffer doing the "right" thing - and using existing standards
APIs where it is possible - JAAS for authentication is pretty clear.
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?
All the code
I've seen is checking for a security manager - because the contract is that
without a secuirty manager you shouldn't enforce the policy. However the
Policy object ( or some implementation ) should just work without the SM.
I'm fine with the idea if we can come up with something that has the
same behaviour with a SecurityManager. When running under the security
manager, we should be 115 compliant.
Regarding use of JMX - well, JMX should be used to enable management of
whatever authenticator/authorizer module we use ( attributes, runtime info,
etc ). We should use JMX notification for callbacks - but only when a
standard API doesn't exists ( or if the standard is too bad or unusable ).
-- Jeanfrancois
Costin
Jeanfrancois Arcand wrote:
Hi,
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
