geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: Jetty and JACC
Date Sun, 23 Nov 2003 21:22:11 GMT
Alan,

> The mapping of Permissions to principals using roles occurs at
> configuration time.  Look at PolicyConfiguration.commit(), this is where
> the mapping takes place and allows for a simple permission check w/ a
> principal instead of mapping roles on the fly.  This is an important
> difference, once commit is called, roles are no longer used since all
> permissions have been directly mapped to principals.

I'm still missing a piece of the puzzle (musn't have had enough coffee 
this morning). I understand that at deploy time for a webapp, the 
web.xml is parsed and a bunch of policy statements are created and 
loaded into the Policy provider. These policy statements are then 
evaluated at runtime by the Policy at the instigation of the container. 
Some checks involve the identity of the user executing the code and the 
roles that the user has been granted. Usually, the roles for a user are 
discovered and cached when the user authenticates . Are you saying that 
this dynamic behaviour is no longer possible and that the container must 
load all users and their roles once-only at deploy time instead so that 
they can be mapped to Permissions? If so, then I have two concerns: 1) 
scalability  2) manageability.

Thanks for the JettyWebApplicationContext stuff, have you committed it?

cheers
Jan

> When you login using the registered GeronimoLoginConfiguration, see
> LoginPropertiesFileTest for an example, the LoginModuleWrapper creates
> an AccessControlContext for the authenticated Subject and registers that
> context w/ that subject.  When a user makes a call on the interceptor
> stack, the Subject gets pushed into the context via 
> 
> ContextManager.pushSubject(subject);
> 
> When you do a permissions check, see EJBSecurityInterceptor, the
> AccessControlContext that is associated w/ the Subject is grabbed and
> checkPermission is called.  This call, in turn, calls the registered
> Policy provider, see GeronimoPolicy.implies().
> 
> 
> I am contemplating the idea of having container providers provide a
> PolicyConfiguration factory for their containers.  These
> PolicyConfigurations would be optimized for the abilities of their
> containers.  For example, the generic Geronimo container passes around
> the Method instance per call.  The OpenEJB Nova container has a method
> index making certain optimizations, e.g. using bitvecs for permissions,
> available.  OpenEJB Nova would register its own
> PolicyConfigurationFactory for its containers for the security server to
> use.
> 
> 
>>I'd like to start integrating Jetty's authentication mechanism with
>>Geronimo's. I've had a quick look in the core security package.
> 
> Anything
> 
>>special I need to know?
> 
> 
> I've already started to take a crack at this.  Here's a piece.  You have
> to set the MBeanServer for the GeronimoLoginConfiguration since there
> can be multiple MBeanServers in the JVM.  (I'm not particularly pleased
> w/ the way I have to do this and would appreciate some ideas on this)
> The call to PolicyContext.setContextID() sets the context id which my
> Policy implementations uses to pick up the right PolicyConfiguration.
> 
> 
> public class JettyWebApplicationContext extends WebApplicationContext {
>     private Context componentContext;
>     private MBeanServer server;
>     private String contextID;
>     private Log log =
> LogFactory.getLog(JettyWebApplicationContext.class);
> 
>     public JettyWebApplicationContext() {
>     }
> 
>     public JettyWebApplicationContext(String webApp) {
>         super(webApp);
>     }
> 
>     public Object enterContextScope(HttpRequest httpRequest,
> HttpResponse httpResponse) {
>         log.info("Entering context " + httpRequest.getRequestURL());
>  
> RootContext.setComponentContext((ReadOnlyContext)componentContext);
>         GeronimoLoginConfiguration.setMBeanServer(server);
>         PolicyContext.setContextID(contextID);
>         return super.enterContextScope(httpRequest, httpResponse);
>     }
> 
>     public void leaveContextScope(HttpRequest httpRequest, HttpResponse
> httpResponse, Object o) {
>         super.leaveContextScope(httpRequest, httpResponse, o);
>         RootContext.setComponentContext(null);
>         PolicyContext.setContextID(null);
>         log.info("Leaving context " + httpRequest.getRequestURL());
>     }
> 
>     public Context getComponentContext() {
>         return componentContext;
>     }
> 
>     public void setComponentContext(Context componentContext) {
>         this.componentContext = componentContext;
>     }
> 
>     public MBeanServer getServer() {
>         return server;
>     }
> 
>     public void setServer(MBeanServer server) {
>         this.server = server;
>     }
> 
>     public String getContextID() {
>         return contextID;
>     }
> 
>     public void setContextID(String contextID) {
>         this.contextID = contextID;
>     }
> }



Mime
View raw message