Re: Jetty and JACC

[Jan Bartel]

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;
    }
}