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.
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]>
