A cup of Java

As J2EE Security freelance I get to design/startup develop a lot of systems that require bulletproof security features. Over the years I've noticed that the only way to design secure systems is by keeping the authentication and authorization mechanism as simple as possible. The Keep It Simple, Stupid (KISS) principle must be respected at all cost when it comes to security.

At Sun they also understand this principle when you look at the security framework provided in EJB. In EJB3 the security constraints are expressed via some very simple annotations. Basically you annotate a class or method with @RolesAllowed("the role") to activate the role-based access control (RBAC) on the component. When you're using the JBoss Application Server (AS) you have an extra annotation called @SecurityDomain("name") to mark in which security domain the component is living. Besides the configuration of the security domain via JAAS login modules there is nothing more to it. In practice you can setup the security domain via a JBoss Service SAR package, which you can bundle as part of your application itself. This limits the deployment to one single EAR, which is as painless as it gets.

So far for the EJB architecture. When you look at the servlet front-end you notice another approach as it comes to security. Instead of annotating components, you select via web.xml which web resources require which role. Besides this there's another aspect. Because the servlet container directly communicates with the client-side brower it also has to define the authentication interfacing mechanism itself. In my view the servlet specification is way off in this area. And now, with web frameworks like JSF even the web resources based security role assignments are not making much sense anymore. The solution is quite simple: don't use servlet container security, it sucks.

This has led to a certain security vacuum in JSF application development. This because initially the backing beans weren't EJB session beans and thus had no EJB security aspect applied to them. People had to come up with some custom made security framework to emulate RBAC on the backing beans. This all changes when JBoss came up with Seam. In this component framework they made EJB session beans to act as JSF backing beans. This allows us to apply all EJB aspects onto the backing beans, so we can have EJB RBAC working again. Remember, one of it's strengths is KISS.

In my view the approach should changed as it comes to securing MVC applications like Seam JSF web applications. It does not make sense anymore to secure the view components when you have an MVC model with strict separation between the view an control components. The view components (JSF pages) only (1) format the data that comes from the control components (Seam BBs) and (2) present the possible operations that the user can invoke on the control component (Seam BBs). Thus if you apply the security aspect on the control components (and model component) this should do the trick. There is no added value in securing the shallow view components (JSF pages) anymore. This of course only holds when the view components always have to pass through the control components to acquire data or to invoke an operation. Though this does not take away that the view level cannot have notion of the active principal.

And here I completely disagree with what JBoss is doing in Seam as it comes to security. JBoss wants to push in the usage of their rules engine into Seam to also have security at the view level. That's probably one of the drawbacks of using a very popular open source package that is driven by one big software vendor like JBoss. They notice the success of one of their products (i.e. Seam) and try to gain better visibility of their other not so successful products (Drules, ...) via this successful one. This while it doesn't bring anything to secure the view level of your MVC Seam application anymore. There's also the fact that people are used to secure the view level and will not leave this habit that easy. So we're fed up with a quite complex (check out the Seam tutorial) Seam security module that is completely violating the KISS principle. I'm really interested in how the Seam community will adopt this new security framework. I for one am going to stick for a while with the proven and rock solid EJB RBAC model.