Dynamically registering WebFilter with Java EE 6

Markus Eisele
5
Yeah. Security. I start loving this stuff. I have a nice little application running with Java EE 6. And if you are following my posts lately, you know, that it has little more security requirements than usual and therefore we definitely have some custom filter logic in place. The javax.servlet.Filter is a great place to start, if you are looking for a way to implement cross cutting concerns.
CC BY-NC 2.0 by aftab
Filters perform filtering in the doFilter method. Every Filter has access to a FilterConfig object from which it can obtain its initialization parameters, and a reference to the ServletContext which it can use, for example, to load resources needed for filtering tasks.
Beside Logging and Auditing, compression and conversion this is also suitable for placing security related stuff.
Beginning with Java EE 6 the implementation is straight forward and easy.
Add a @WebFilter annotation to your implementation class and you are done:

@WebFilter(dispatcherTypes = {DispatcherType.REQUEST, DispatcherType.FORWARD}, urlPatterns = {"/something/*"})
public class SecurityFilter implements Filter {
...
}


Problem
But: What to do, if you are running different environments and you have some very heavy filter logic in place, which in fact depends on other infrastructure components placing header variables or other stuff into the request before processing? You have to disable them in development. Enable them in production or integration testing.
Building for different environments basically is not a big issue, but you end up commenting in and out the @WebFilter annotation. That ...cks.

Solution: Dynamically register your WebFilter
But hey, the Servlet 3.0 API is here. And you are able to register your components dynamically. A good place to register filters is a ServletContextListener. And you don't even have to forgo your beloved annotations. Let's start with the basics.

@WebListener
public class FilterStartupListener implements ServletContextListener {

@Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext ctx =
sce.getServletContext();
...
}
}

Next is to find any way to figure out, if you are running in production mode or not. You could think about using a system property or even reading the projectStage property from your JSF implementation. Whatever you chose, the magic happens here:

if (Util.isProduction()) {
// if we are running in production mode
// register with servletContext
FilterRegistration fr = ctx.addFilter("SecurityFilter", SecurityFilter.class);
fr.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST, DispatcherType.FORWARD),
true, "/something/*");
}
}

That's it. It does all the magic for you and you no longer have to care about them. If the property of your choice changes, your filters get registered dynamically or not.

Post a Comment

5Comments

  1. Nice article, this can really be useful. The only thing: in my opinion, most security concerns should be based on standard Java EE security (login modules, declarative security, ...) instead of a custom filter.

    ReplyDelete
  2. Hi Yannick,

    thanks for your comment. You are partly right. There are some requirements, which could not be solved with the Java EE standard security mechanisms. The only way out are filters ...

    Rgds,
    M

    ReplyDelete
  3. Hi, I partly agree ;-) What cannot be done using standard Java EE security should be done with filters.

    ReplyDelete
  4. If you have not done so already, take a look at the Servlet Profile of JSR 196; which is required to be supported by all Servlet containers of EE 6 full-platform compatible application servers. Unlike Servlet filter based approaches, the Servlet profile ensures that the authentication result set by the pluggable module, is applied in the access control processing performed by the Servlet container. The profile is also well suited for the 2-mode configuration problem you have cited. More examples of its use are emerging with the arrivalof compatible EE 6 containers. The one unfortunate downside; which we hope to rectify, is that the Servlet 3.0 spec only recommends support for the contract; which means that it may not be supported in some lightweight 3.0 compatible Servlet-(only) containers. If you would like more info let me know.

    ReplyDelete
  5. A very nicely done article. Concise and to the point. Thanks for sharing.

    ReplyDelete
Post a Comment