9.4 JAAS and J2EE

As discussed so far in this chapter, JAAS addresses authentication and authorization functions in a Java environment. In previous chapters, we saw how J2EE security is defined and used. Within J2EE, the preferred approach for performing authentication, authorization, and delegation is declarative. In some cases, the declarative approach is insufficient. One example is a servlet performing a programmatic login. There are two approaches: using container-supplied APIs, and implementing the security policies within the application. When using the container-supplied APIs, the results ”for example, authentication ”will be consistent with the operations performed by the container. The disadvantage is that this approach is not standardized, and the code is likely to be nonportable.

When the security policy is implemented within the application, the preferred approach is to use the existing J2SE and JAAS security mechanisms. This guarantees portablity of the code, but the results ”for example, authentication ”may not be consistent with the container. For example, there is no formal relationship between the getCallerPrincipal() method in interface javax.ejb.EJBContext , as defined in the EJB specification, and the Principal objects contained within a Subject , if it exists, during the execution of an EJB method.

The following subsections explain how JAAS fits into a J2EE environment. They also discuss some of the technical issues developers should be aware of when using JAAS from within their J2EE applications.

9.4.1 Web Application Servers Executing in Various JVMs

A developer can use the JAAS functionality from within a J2EE application. This is required to be supported by J2EE-compliant WASs (see Section 2.3.1 on page 33). What this implies is that developers can use JAAS from within their applications, including performing logins and authorization tests. There are container-specific configuration issues that deployers must consider. For example, updating the Java policy file may not affect the Permission s granted to a Subject . This occurs when the WAS has its own Policy implementation ”for example, an existing authentication/authorization infrastructure ”or a more sophisticated mechanism to specify policies that do not rely on the default policy file implementation. There are also product-specific ways to configure LoginModule s.

The J2EE specification allows J2EE applications to use the JAAS API. However, the J2EE specification does not require J2EE containers to use JAAS for their authentication and authorization mechanisms. This implies that using JAAS within a J2EE application need not have any effect on the security context of an executing J2EE application. For example, if a servlet invokes an enterprise bean within a Subject.doAs() method block, the identity under which the enterprise bean is invoked need not be the identity represented by the Subject instance. Therefore, the effective identity within a J2EE environment need not be the identity represented within the Subject . Container-supplied APIs may offer solutions to the problem of programmatic delegation but at the cost of nonportability.

9.4.2 JAAS Subject in a J2EE Environment

In Section 9.3.2.1 on page 317, we explained how an application can access authenticated- user information by calling the Subject.getSubject() method. This method returns a Subject instance containing the credentials and Principal s of the entity currently executing on the thread. J2EE WASs are themselves Java applications. Also, beginning with V1.3, J2EE has supported JAAS. Application developers may therefore assume that a WAS uses JAAS to perform authentication. ^[4] Based on these assumptions, a servlet or an enterprise bean may incorrectly attempt to access the authenticated Subject information by calling Subject.getSubject() . Such a call may result in a null being returned, because the WAS is not required to implement its authentication using JAAS and may not have dispatched the servlet or enterprise bean from within a Subject.doAs() call.

^[4] Section 15.2.2 on page 531 discusses how J2EE containers can be designed to use JAAS to perform authentication.

Subject.doAs() provides the capability to execute downstream method calls under the identity of the specified Subject . However, this is true only if the calls are localized within a single JVM. In case of a servlet invoking an enterprise bean, the call is likely to traverse process and JVM boundaries. Therefore, the identity under which a target enterprise bean is invoked may not be the same as the identity that was logged in as a result of the call to LoginContext.login() .

9.4.3 Bridging the Gap

When originally defined, the J2EE authorization model was different from the Java 2 security permission model (see Section 8.6 on page 267). To bridge the gap between the J2EE and J2SE security models, Java Specification Request (JSR) ^[5] 115, "Java Authorization Contract for Containers," has defined J2EE roles as sets of Java 2 Permission s and their use in authorization for resource access. The specification has also defined how the Java 2 permission model and JAAS can be used to address authorization requirements from within a J2EE environment.

^[5] JSR details can be found at http://www.jcp.org.

JSR 115 does not resolve all the outstanding issues between J2EE and J2SE security. In particular, the process of authentication within a J2EE container is still not required to be based on JAAS. However, JSR 196, "Java Authentication Service Provider Interface for Containers," is expected to focus on how JAAS is used to address J2EE authentication requirements. JSR 196 will also help address some of the issues discussed in this chapter, including the relationship between the Principal object resulting from getCallerPrincipal() and the list of Principal s within the Subject instance that resulted from the user authentication.

9.4.4 Enterprise Security Policy Management

Once security policies are defined, the next challenge is creating an authorization policy store that scales well. Large enterprises often have many deployed applications spread across a set of heterogeneous operating platforms and J2EE-container vendors. Without the appropriate administration tools, it is practically impossible to provide a single and consistent view of the security policy in such complex distributed heterogeneous environments. One approach, as explored by JSR 115 and the security-services vendors, is to define security-services contracts for J2EE containers. These contracts, in the form of APIs, allow the J2EE containers to plug in security services from multiple vendors. The vendors providing the security services also provide the security-service management in distributed computing environments. In this way, it is possible to consistently manage the security policy of distributed heterogeneous environments across the enterprise. One example of such security-service management is provided by Tivoli Access Manager, formerly called Tivoli Policy Director.