On Sep 17, 2010, at 5:36 PM, Ivan wrote:
2010/9/18 David Jencks <firstname.lastname@example.org>
On Sep 17, 2010, at 12:44 AM, Ivan wrote:
> 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
I'm not sure what you mean here, but I haven't looked closely at SpecSecurityBuilder. Could you be more specific?
> 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.
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.
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?
> 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.
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
public Set<String> setServletSecurity(String servletName, ServletSecurityElement securityElement);
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.
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.
> Thoughts ?
> To David. I found you did some code changes for Jetty now, and wonder whether you have bugun some simliar work ?
> Thanks !