geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Support dynamic security configurations for web access control
Date Wed, 21 Apr 2010 17:16:27 GMT

I would be a lot happier moving to jaxb objects for this.  How much work do you think it would
be to use jaxb for web.xml?  I'd think the major problem would be in the naming builders.
 I wonder if we could put some default jaxb <> xmlbeans conversion methods in the AbstractNamingBuilder
and each builder could override one to do the actual processing.

I think we need to change when the security calculations take place so the conversion from
constraints to permissions happens once after these runtime constraints are added.

Even after we've added the security constraints, we might need a way of programatically adding
principal<> role mappings as well.

Do you think it would be practical to allow adding/removing security constraints and principal<>
role mappings after the app has started?  I was thinking of letting you change the security
model with arbitrary calls and then have "commit" method that would replace the existing model
with the new, modified model.

david jencks

On Apr 20, 2010, at 7:39 AM, Ivan wrote:

> Hi,
>     While working to support some new security configurations in Servlet 3.0 web deployment
xml file, I realized that we might need to support dynamic security configuration for web
access control. As in Servlet 3.0, it is allowed to configure the security constrait while
initializing the web modules using ServletRegistration.Dynamic interface. However, in the
past, all of the permissions are calculated in the deployment process. So now, from my view,
we might need to re-envaluate the security constraint configurations from scratch. Currently,
My initial mind is to create a Geronimo servletcontext and servletregistration.dynamic impl
based on Tomcat's , and add all the new security configuration data to the xmlbean object
while users invoke setSerlvetSecurity methods, then we re-calculate the permissions again.
>     Anyone has other better ideas ? Thanks !
> -- 
> Ivan

View raw message