Filip Hanik wrote:
Any idea how they manage this scenario (I can look at the code but I would prefer some feedback from you first :-) ). Seems we can "patch" the problem internaly (if a jaas only solution isn't available).In JBoss they have the following problem with JAAS. You protect /myapp/secure, the user logs on. When the user is in another subcontext, for example, /myapp/nonsecure/ JAAS doesn't return a user principal at all, because that subcontext was not marked for being secure.
-- Jeanfrancois
just an fyi
Filip
-----Original Message-----
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [5.0] Splitting authentication and authorization.
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.
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.
+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. 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.
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 ).
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
