JAAS, the Java Authentication and Authorization Service, is the standard Java mechanism to authenticate users to an application (the authentication part), and then ensure that only authorized users access certain resources (the authorization part).

While JAAS is a well thought-out API, and is widely used, integrating JAAS's view of Java security into a J2EE application has been rather difficult. In a recent java.net article, Using JAAS in Java EE and SOA Environments, Denis Pilipchuk points out that,

At the moment, there are three major sore spots in this integration (or lack thereof):

• There is no binding defined for JAAS authentication for a Java EE Servlet authentication mechanism.
• JAAS and EE rely on different representations of a user's identity.
• Permission mapping, and therefore authorization, is not consistent between EE application layers.

Pilipchuk goes to discuss the mismatch between the JAAS and J2EE notions of an authenticated user, or subject:

One of the greatest integration problems lies in the different approaches to user representation in JAAS and Java EE worlds... This is where the integration never really took place, and which has been and still remains the greatest source of incompatibility...

Unfortunately, the relationship and conversion rules between these two different representations have not been specified in either direction. This means that, given a Subject, a Java EE container will use a vendor-proprietary algorithm for selecting one of its Principals to use in the EE API. And, given a Principal, there is no standard way to retrieve the associated Subject for it to use in the JAAS API.

The article also discusses the problems with using JAAS's authorization scheme in J2EE:

Directly related to the problems around Subject propagation is the user policy issue. If the same user may be associated with different Principal sets contained in multiple Subjects, depending on which part of the system you are looking at, imagine what havoc it wreaks for authorization policies...

The second authorization issue...has also been known and discussed for a number of years, but nothing has changed. First, after introducing JAAS into [the] J2SE security architecture, the doPrivileged() method of java.security.AccessController was not updated, which led to cutting off the current Subject in Subject.doAs() calls... Since J2EE places a requirement to propagate the current call Principal from servlets into EJBs, the runtime behavior is undefined.

In conclusion, the article points to JSRs 115 and 196 as solutions to this integration problem.

If you currently use JAAS in a J2EE application, what are your biggest challenges in integrating these frameworks?