http://www.jboss.org/forums/thread.jsp?forum=49&thread=26355&message=3758564&q=userrole#3758564
don't think they had a solution Filip -----Original Message----- From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 10:54 AM To: Tomcat Developers List Subject: Re: [5.0] Splitting authentication and authorization. Filip Hanik wrote: >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. > 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). -- 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]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
