J2EE Security: JAAS or declarative J2EE security ?

J2EE Security: JAAS or declarative J2EE security ?

Is there a need for a JAAS framework for Web application security?

With the Java Authentication and Authorization Service (JAAS), recently added as an official component to the J2EE platform, and the standard declarative J2EE security model, implemented in the J2EE containers, it seems that there exist two tools that obviously do the same thing. It therefore doesn’t come by surprise that application developers seem to be trapped by which options to choose when building Web applications.

Declarative J2EE security is role based, which means that user populations are authorized based on their group memberships. Declarative J2EE security is code independent and doesn’t need to be known by the developer when creating the application. For complex access evaluations, declarative security can be checked programmatically in calls to isUserInRole() or isCallerInRole(). The role name used in an application code can later be mapped to an existing security role name in the web.xml file, using the element. This clearly separates application code from the security definitions.

JAAS is the technology of the moment with a lot of buzzin’ around it. Compared to declarative security, the JAAS implementation doesn’t allow the decoupling of application code and security code to the same extend. However, JAAS is finer grained in that it can protect individual code sources based on the user (Subject) running it, and also seems to be more powerful.

In JAAS, a user is granted a set of Permissions that are evaluated by a call to checkPermission() when the application code is executed.

Historically, JAAS was designed for the Java 2 Standard Edition (J2SE) where it still is located in, but made its way to the J2EE web stack.

The Web, also historically, is using the declarative J2EE security, which is much better integrated in J2EE containers than JAAS. Web technologies like Apache Struts by default support the declarative J2EE security in the framework and its Tag Libraries.

Sitting here and preparing for my presentations and demo ground duties at this year’s OOW in Sao Paulo, I thought of doing a quick search on what’s available for protecting Web applications with JAAS and how JAAS is used in Web applications.

Two open source frameworks, beside of vendor specifiv implementations like on Oracle Application Server and BEA Weblogic, are what I could find: jGuard and Gabriel.

The approaches of Gabriel is aspect oriented and similar to what’s described in chapter 10 “Authentication and Authorization” of the book “AspectJ in Action” by Ramnivas Laddad. jGuard is interesting in that it handles security permissions in the database, which sound like a good idea for Oracle customers that historically used the database for all kind of application configuration and that don’t want to use Oracle Internet Directory as a central repository for end-to-end security.
From a first glance, Gabriel missed the concept of roles and groups, which greatly helps to simplify security administration. Using roles, the actual JAAS permission is granted to the role Principal, which then is applied to the authenticated Subject.

One of the reasons why you want to use a framework for authentication and authorization – if using JAAS – is for consistency because security has to be the same on all layers – view, controller and model – involved in creating and running J2EE applications.

Next search was for Java ServerFaces (JSF), just being curious for what the expert group has decided to use in their default implementation. Again, not a surprise, JSF relies on declarative J2EE security and not JAAS. I understand this decision because JSF ships as a view layer technology and isn’t supposed to provide a general security framework for JAAS.

The conclusion of my investigation is that JAAS shows okay and greatly adopted as a technology, but still lacks an agreed standard framework for securing Web applications including the controller and model portion.

Something Apache Struts like for JAAS security would be good to have. Preferably, having a JSR for it could ensure that the implementation of JAAS security for web applications is neither vendor nor implementation specific.

Based on this work, tag libraries would be developed that enable JSF applications to leverage JAAS for security. JSR-196 expose JAAS security so that it can be used with declarative J2EE security, but this doesn’t seem to be enough.

For those that work with Apache Struts today, its not a big deal to change the Request Processor object to evaluate JAAS permissions instead of processing J2EE roles, but this still doesn’t solve the problem of the lack of a standard security framework for J2EE applications.

I am sure we will see future improvements around this topic.

Frank