geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Enable Declartive Security in Jetty ?
Date Sat, 18 Sep 2010 06:49:06 GMT

On Sep 17, 2010, at 5:36 PM, Ivan wrote:

> 2010/9/18 David Jencks <>
> On Sep 17, 2010, at 12:44 AM, Ivan wrote:
> > Hi,
> >     While looking at some Servlet Security JIRAs, I begun some code refactors on
the SpecSecurityBuilder, including :
> >     a. Add more Info class for the security configurations, and serialize those
in the .ser file, with them, it would avoid the xml parsing on the startup time and make the
codes look simple
> excellent idea!
> >     b. Use ServletContext more in the SpecSecurityBuilder, as it is more helpful
for some calculations, such as get the mapping urls for the target servlet.
> I'm not sure what you mean here, but I haven't looked closely at SpecSecurityBuilder.
 Could you be more specific?
>  e.g. Use the method ServetContext.getServletRegistration().getMapping could eaisly get
all the url patterns of the target servlet. 

I don't think this will be ideal.  It won't work except for servlets where the security is
set through the servletRegistration rather than through web.xml, since the url patterns in
web.xml don't have to be servlet mappings.  For jetty, I think a more "native" solution will
work better, see below.
> >
> >     To make these functions work, especially the option b. it requires to enable
declarative security in Jetty integration, generally speaking, will adopt the same way as
Tomcat integration does,
> >     a. create a Wrapper class for ServletContextHandler.Context class, so that we
could monitor those new added dynamic servlets. One thing might be care is that the codes
need to distinguish the servlets from web.xml, as they are also added by ServletContext now
in Jetty.
> >     b. Add a EventListener to ServletContextHandler, it will be resposible for the
security calculation and fill it into ApplicationPolicyConfigurationManager.
> >
> I think you mean "declarative security for servlets added by the addServlet methods on
ServletContext"?  Jetty will want to deal with that too, so I think putting something in the
jetty code that calls out to a security builder of some kind (we can install our own) is the
best plan here.  Then we shouldn't need more wrapping.  Maybe I don't understand exactly what
you mean?  What would the event listener do?
>   In the Tomcat integration, a JACCListener is attached to the web context, while it
receives the initialize event, a specsecuritybuilder is created, while the started event is
received, it will build the permissions and fill the result to the policymanager.
>   We need wrapper here, especially in Jetty now, since all the servlets are registered
dynamically, for jetty itself, it will not know what to return for some methods, e,g, ServletRegistration.Dynamic.setServletSecurity
method, it needs to return all the un-affected url patterns. Also, since most of the security
related issues are handled by Geronimo, there is no need to call the initial codes. 

Right now this is not implemented in jetty at all.  I think we should define an interface

ConstraintStore {
            public Set<String> setServletSecurity(String servletName, ServletSecurityElement

that the ServletRegistration will delegate to.  Our implementation can implement it based
on the info tree from the deployment descriptor.  When we start the context we can convert
the ServletSecurityElements and url mappings to info, and proceed to generate the permissions.

It looks to me as if the return value from the spec setServletSecurity is of limited use because
you can set the security element on your servlet registration before you set any servlet mappings,
so you wont  find out about any conflicts with the xml dd.

david jencks


> >     Thoughts ?
> >      To David. I found you did some code changes for Jetty now, and wonder whether
you have bugun some simliar work ?
> I was thinking about doing something like this but haven't started anything.  I did look
a little bit into configuring tomcat using the info tree rather than letting tomcat read the
web.xml.  I've found a bunch of tomcat problems and spec inconsistencies.  I haven't gotten
to security configuration yet.
> thanks
> david jencks
> >      Thanks !
> > --
> > Ivan
> -- 
> Ivan

View raw message