Since 2001 when Java Authentication and Authorization Service (JAAS) was formally included in the Java 2 Platform Enterprise Edition (J2EE) 1.3 platform specification, the J2EE community has been grappling with the issue of JAAS/J2EE integration. On the surface, JAAS seems to be an excellent complement to J2EE: JAAS defines a pluggable Application Programming Interface (API) for authentication modules and a fine-grained Subject-based authorization model, which are both lacking in the existing J2EE security model. Since JAAS is officially part of the J2EE platform specification, it's not unreasonable to expect that you can now leverage the JAAS framework to build portable enterprise applications that have advanced authentication and authorization requirements. Unfortunately, any Java architects or developers who go down this path for their applications will soon be confronted with the harsh reality: Instead of finding a landscape defined by an unified integration architecture, they'll discover a landscape littered with incompatible vendor-specific APIs and frameworks.

If JAAS and J2EE seem to fit well together, why is there such a fragmented landscape? What has contributed to this fragmentation, and more importantly, what lies ahead? In this article we'll explore the main security issues that architects and developers must consider when designing J2EE-based solutions for enterprise deployments. We'll also highlight some of the ongoing standards-based efforts that will make it easier to include advanced authentication and authorization capabilities in your enterprise applications. Finally, we'll offer some pragmatic strategies you can consider today, while waiting for the standards to catch up.

JAAS and J2SE
JAAS is designed to bring Subject-based authentication and authorization to the Java 2 platform. On the authentication side, JAAS is modeled after the Pluggable Authentication Module (PAM)-a popular API for defining authentication modules in a portable and extensible manner. On the authorization side, JAAS inherits the rich, fine-grained, and extensible security model defined in Java 2. When JAAS was first introduced as an optional package for JDK 1.3, there was, understandably, quite a bit of excitement: "Finally, a real security standard for the Java platform!" (Not that code-based security isn't important, but a lot of us were waiting for a user-based authentication and authorization model.)

Indeed, JAAS 1.0 did achieve a few significant wins for Java developers. It offered a standard way to develop authentication modules (via JAAS LoginModules - see Figure 1) and a flexible way for the authentication modules to gather information dynamically from the application (via CallbackHandler - see Figure 2). It also offered a way to integrate Subject-based authorization into the Java 2 platform without affecting the code-based security model.

Of course, being hard-nosed, pragmatic people, we were also realistic - or so we thought - in our expectations: "It's only Version 1.0 of this API, and it's released as an optional extension, to boot. It'll probably be a few years before it goes mainstream."

Not surprisingly, when JAAS 1.0 was introduced, there were a few issues. As an optional extension, the JAAS jar files weren't generally available as part of the regular JDK distribution. In addition, its add-on nature was reflected in the API design - instead of having one policy that dealt with both Subject- and code-based policies, we had to deal with two separate policies (each with its own API) and some obscure DomainCombiner logic that updates the protection domains based on these policies at runtime.

Fortunately for Java developers everywhere, these issues largely went away when JAAS was fully integrated into the core Java security architecture in JDK 1.4: JAAS was distributed as part of the regular JDK distribution, and the Java 2 security model is now the JAAS security model - one security model, one policy API. (Please refer to Java 2 Security Architecture ( http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html) for more details about JAAS/J2SE security model.)

JAAS and J2EE
Most Java developers would agree that if there were a Java development platform that could really benefit from a user-based authentication and authorization standard, it would be the J2EE platform, where security is paramount and user-based security, in particular, is essential to any enterprise-ready applications. Thus J2EE, unlike J2SE (Java 2 Platform Standard Edition), came with a rather sophisticated user-based security model since J2EE 1.0. With the introduction and subsequent integration of JAAS into the J2SE platform, the main question has now become: "How do we integrate JAAS into J2EE?" (This is a question Graham Hamilton posed to the Java security experts at a one-day Java security summit held in Boston shortly after JAAS 1.0 was introduced.)

On the surface, it appears that JAAS and J2EE complement each other very well. Although J2EE defines a declarative way to configure the authentication method to be used with a Web/EJB module, it doesn't define a pluggable authentication module API; JAAS (with its LoginModule API) nicely fills this void. And although J2EE authorization serves quite well the security needs of typical (security-unaware) Web-based and EJB-based applications, it's also a rather coarse-grained and inflexible model (the only privileges supported are URL-based and EJB method-based). The JAAS/Java2 permission-based model is extensible and can model arbitrarily complex and fine-grained authorization policies.

Given these considerations, it wasn't surprising that shortly after its introduction, JAAS 1.0 was included as part of the J2EE 1.3 platform specification. Unfortunately - perhaps due to time and resource constraints - there were no provisions in the J2EE 1.3 specification regarding how JAAS 1.0 was to be integrated into J2EE-compliant containers. In other words, it'd be up to each container vendor to figure out the right integration strategy. Inevitably, because different vendors decided to do this in different enough ways, the fact that JAAS 1.0 was officially part of J2EE 1.3 isn't very meaningful to Java developers - at least to those who care about developing portable J2EE applications.

• Consider authentication: While it's possible to write a JAAS-based login module that works properly in a J2EE 1.3/1.4-compliant container, it'd be difficult - in fact, almost impossible - to write one JAAS login module that works equally well in all J2EE 1.3/1.4 containers.
• Consider authorization: While it would be possible for a J2EE application to use the JAAS policy API and Java 2 permission model to handle fine-grained authorization policies, it'd be impossible for such an application to retrieve the JAAS Subject (representing the currently authenticated user) in a portable manner.

First, let's consider authentication: JAAS has defined a portable, extensible API for authentication modules that lets you reuse a well-behaved LoginModule implementation in different contexts. What does this mean in a J2EE context? We believe a reasonable goal for a JAAS/J2EE integration architecture would be to let any JAAS-compliant login module be plugged into any J2EE-compliant container - without any modifications. In other words, you should be able to develop or buy/download an RDBMSLoginModule to use with your applications and expect it to work well in all J2EE-compliant application servers that might end up hosting your applications. Given certain reasonable constraints (for example, the RDBMSLoginModule shouldn't use any protocol-specific Callbacks), it should also work equally well for most of the managed resources (such as servlet/JSP, EJB, or MBeans) over a variety of connection protocols (such as HTTP, RMI/IIOP, or JMX/RMI).

Now, let's consider authorization. We believe a properly designed integration architecture should cover the following: First, the J2EE authorization model should work properly in a JAAS/J2EE context. In other words, using a JAAS LoginModule to handle authentication for your application doesn't mean you want to get rid of the nice declarative security constraints you've worked hard to exactly fit your application. Also, the managed component (such as Servlet/JPS, EJB, or MBeans) should be invoked in an execution context where the currently authenticated user (represented by a JAAS Subject instance) is readily available (via JAAS API) to the component. (In standard JAAS, this typically means the managed component is invoked within a Subject.doAs[Privileged] block.) Finally, the legacy J2EE authorization API (such as isCallerInRole/getCallerPrincipal) should work properly in a JAAS/J2EE context; this means that if your application is security-aware and uses isCallerInRole to do advanced role-based processing, your application should continue to work in a JAAS/J2EE-integrated environment.

So far, we've only outlined the basic requirements; these ensure that JAAS and J2EE play well with each other, and that the legacy applications or modules developed with either context in mind continue to work well in an integrated environment. A JAAS/J2EE integration framework that implements these requirements in a reasonable manner might be considered a solid investment, but probably not something worth jumping up and down about.

Yet these basic requirements do bring about a level of power and sophistication not seen before in J2EE security. For instance, by leveraging the integrated JAAS/J2EE architecture, you can finally build advanced enterprise applications that authenticate via a custom (application-specific) user repository (via standard JAAS LoginModules); leverage a coarse-grained J2EE authorization model for pre-dispatch authorization decisions; and leverage a customized, fine-grained JAAS permission model to protect application-specific resources. And you achieve all of these without sacrificing portability.

This is nothing to be sneezed at - and if you're like us, you're probably salivating at the possibilities this combination has opened up for your application architecture...

Not so fast. Yup - there's a catch.

The Current Landscape
Equipped with this modest list of requirements, we're ready to evaluate the current landscape. As an industry, how do we fare in this context? In a nutshell, not very good. In fact, if we use this basic requirement list as a scorecard, most vendors wouldn't do well at all.