Monday, January 29, 2007
Seam seems seamless on security?
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.
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.
Friday, January 19, 2007
Maven2 - One year later
About one year ago I switched from Maven1 to Maven2, leaving behind the Ant-isch way of building my software components. Over this year I've started 3 major SOA projects out of which 2 are new products and a few small, i.e. < 20k LOC, projects. Was it worth switching to Maven2? Definitely, though obviously it didn't go as a free lunch. It is very clear that the setup of a software factory using SubVersion, Continuum and a Maven repository is key to manageable software projects. You need to have version control, regression control and release management via a shared software repository. It is reassuring to see that the big players like Sun and JBoss also embrace these principals, and even are/start using Maven2 public repositories to publish the latest releases of their components under development. By sniffing the Sun Maven repository you can even predict releases of their major products like JAX-WS RI.
What Maven2 is still missing is the notion of J2EE dependency contexts. The dependency scoping is not expressive enough in my view. It's very difficult to express, for example, that if dependency X is provided by the EAR, that it should not go into the WAR. And if the container provides X, it should even not go into the EAR at all. Of course some of there rules are very dependent on the class loader behaviour of the container (which is a lot of fun in JBoss AS) wherein you want to deploy your application. Maybe that's why this problem has not yet been tackled to the full extend it should have.
I also get to hear quite often that Maven lacks documentation. This is the general case for most Free Libre Open Source Software (FLOSS) out there, simply because there is no legacy marketing engine behind these projects that forces the developers to produce tons of documentation. "Use the source, Luke." is most of the time the only way to understand how things work. And I for one prefer it that way since it prevents developers from hiding behind bad excuses.
What Maven2 is still missing is the notion of J2EE dependency contexts. The dependency scoping is not expressive enough in my view. It's very difficult to express, for example, that if dependency X is provided by the EAR, that it should not go into the WAR. And if the container provides X, it should even not go into the EAR at all. Of course some of there rules are very dependent on the class loader behaviour of the container (which is a lot of fun in JBoss AS) wherein you want to deploy your application. Maybe that's why this problem has not yet been tackled to the full extend it should have.
I also get to hear quite often that Maven lacks documentation. This is the general case for most Free Libre Open Source Software (FLOSS) out there, simply because there is no legacy marketing engine behind these projects that forces the developers to produce tons of documentation. "Use the source, Luke." is most of the time the only way to understand how things work. And I for one prefer it that way since it prevents developers from hiding behind bad excuses.
