Sketching Out the Auction Security | Special Edition Using Enterprise JavaBeans 2.0

Java Authentication and Authorization Service (JAAS)

Within the J2EE 1.3 and EJB 2.0 Specifications, a new security- related technology for EJB applications called Java Authentication and Authorization Service (JAAS) is introduced. JAAS is a Java implementation of the standard Pluggable Authentication Module (PAM) framework. The goal of the PAM framework is to design an authentication mechanism that is independent of the application layer. In other words, an administrator should be able to plug in various authentication mechanisms on a per-application basis without affecting the application logic itself. You can find more information on the PAM framework at

http://java.sun.com/security/jaas/doc/pam.html

JAAS is a standard extension to the Java 2 SDK 1.3. The Java 2 security model only provides access controls based on where the code originated from and who signed the code. The Java 2 security model does not provide the capability to additionally enforce access controls based on who runs the code. JAAS compliments the Java 2 security model with this type of support. JAAS probably will be part of the core Java language with SDK 1.4 (code name Merlin) when it's released sometime in 2001.

As the name implies, JAAS can be divided into two main components : an authentication component and an authorization component.

Authentication

The authentication component provides the capability to reliably and securely determine who is currently executing Java code. This is true regardless of whether the Java code being executed is an applet, an application, a JSP page, or a servlet.

Note

The authentication capability does not exist with the Java 2 security model. This is absolutely essential behavior for most EJB applications. Prior to JAAS, most applications had to build their own authentication support.

JAAS authentication supports different implementations to be plugged in without affecting the Java application using it. This allows applications to take advantage of the various security authentication technologies without having to rewrite your software. For example, if one customer needed to use a relational database to store user information and another used Lightweight Directory Access Protocol (LDAP), you could just plug in different implementations without negatively affecting the application.

Authorization

The authorization component of JAAS extends the existing Java 2 security framework by restricting users from performing actions depending on who the user is and on the code source. After the user is authenticated, the system obtains the actions that are allowed for this user and remembers this throughout the life cycle of the user's current session with the application.

Note

JAAS supports a security policy similar to the Java 2 security policy. In fact, the JAAS policy is an extension and understands the permissions in the Java 2 policy file like java.io.FilePermission and java.net.SocketPermission .

JAAS Core Classes

The main package for JAAS is the javax.security.auth package. Although three packages exist under the main package, it probably makes more sense to talk about JAAS from a logical grouping of classes, based on what tasks they perform in JAAS. A more logical grouping of classes for JAAS is

Common classes
Authentication classes
Authorization classes

Caution

Don't be misled in believing that the classes are really separated into these groupings. It's more logical for us to discuss them this way, but they are grouped entirely differently.

The Common Classes and Interfaces

Two common components are important to developers using JAAS: the javax.auth.Subject class and the interface java.security.Principal . The Subject represents an entity, such as an individual user or service. A Subject can have many principals, each one associated with a different application service. For example, if an application allowed a user to log in to two different parts of a site and the user used a different username for each part of the site, the user ( Subject ) would have two different principals. The Principal interface we are referring to here is actually the Principal interface that already exists in the Java 2 security framework.

The Subject class has two public constructors:

 public Subject();  public Subject(boolean readonly, Set principals,         Set publicCredentials, Set privateCredentials );

As you'll see later in this section, you also can obtain an authenticated Subject from a LoginContext class, which we haven't defined yet. The Subject class contains methods for getting the set of principals and public or private credentials.

Caution

If you modify the set that is returned from the getPrincipals , getPublicCredentials , or getPrivateCredentials methods in the Subject , the original set will also be modified. Make sure you get a copy if you don't want to affect the original set.

Public and private credentials are not part of the JAAS library. You can use any Java class to represent a credential, including something as simple as the String class.

Earlier you saw how to execute privileged actions using the AccessController class. The Subject class contains two static methods for executing privilege actions as a particular subject. The following methods associate the Subject with the current thread's AccessControlContext and then executes the privileged action by calling the methods on the AccessController class that you saw earlier in this chapter:

 public static Object doAs(Subject subject, PrivilegedAction action );  public static Object doAs(Subject subject, PrivilegedExceptionAction action );

There also are two more methods on the Subject class that, instead of associating the Subject with the current thread's AccessControlContext , the Subject gets associated with the AccessControlContext provided as an argument. The two methods are

 public static Object doAs(Subject subject,                            PrivilegedAction action,                            AccessControlContext ctx);  public static Object doAs(Subject subject,                            PrivilegedExceptionAction action,                            AccessControlContext ctx);

All these doAs methods play a very important role in how the security context information is propagated to a remote container. For example, if a Subject has already been authenticated in the Web tier and invokes a remote operation on an EJB server, the Web tier can use the Subject and Principal information and pass it along to the EJB container, which then can have access to the Principal information.

Note

Keep in mind that the behavior of propagating security context information from the current thread to other J2EE containers isn't unique to JAAS. This behavior is how many J2EE containers perform it already. JAAS merely uses the same techniques.

The Authentication Classes and Interfaces

The classes and interfaces in the authentication logical group deal exclusively with authenticating a Subject in the application. The classes and interface involved are javax.security. auth.spi.LoginModule , javax.security.auth.LoginContext , javax.security.auth. callback.Callback , and javax.security.auth.callback.CallbackHandler .

The LoginContext class provides methods to authenticate a Subject , regardless of the authentication mechanism being used. The LoginContext object uses a javax.security.auth.login.Configuration object to determine which authentication mechanisms to use to authenticate the Subject . The Configuration is associated with one or more classes that all implement the LoginModule interface. Each LoginModule is responsible for authenticating the Subject for a particular authentication service.

Here are the basic steps to authenticate a Subject :

Create an instance of the LoginContext class.
Specify the Configuration file for the LoginContext to use.
The Configuration loads all the LoginModules specified.
The client invokes the login method on the LoginContext .
Each login method in the different LoginModules can associate an authenticated principal with the Subject if the login succeeds.
The LoginContext returns the authenticated Subject to the client.
The client is then free to access the Subject and Principals from the LoginContext object.

We have left a few of the smaller details out here, but the most important steps have been listed and you should get the idea of how this works.

One thing that we have left out of the steps on purpose is discussing how the Callback and CallbackHandler interfaces are involved in the authentication process. These interfaces and the concrete classes are in the javax.security.auth.callback package. They can seem pretty confusing at first, but after you get the picture where they fit in during the authentication process, they make quite a bit of sense. The LoginContext class has four constructors. Two of the constructors take an instance of a class that implements the CallbackHandler interface. Here are the two methods that take an instance of the CallbackHandler interface:

 public LoginContext(String name,CallbackHandler handler)  throws LoginException;  public LoginContext(String name,Subject subject, CallbackHandler handler)  throws LoginException;

The CallbackHandler is passed to each LoginModule in the initialize method. The LoginModule then can use the CallbackHandler instance to make a callback on the client to request information needed to continue with the authentication process. Typically, this information is a username and password. You might be wondering why you don't just pass this information to the LoginContext or LoginModule in the first place. The main reason is that each authentication mechanism is going to be different. Some might use a device to scan the iris of your eyes or scan your fingerprints . By using a callback instead of letting the application handle this up front, the implementation of the authentication mechanism is further decoupled from the application.

There are several concrete classes of the Callback interface for doing things such as getting usernames and passwords. Of course, you can implement your own as well.

Note

There has been some debate on how Web-friendly the callback mechanism is. This is because of the differences between the typical synchronous Web page login and the asynchronous callback. There are some solutions to get around this slight mismatch. One solution involves blocking the original thread until the callback thread acquires the information necessary to complete the authentication process. These issues will be addressed in further implementations.

The Authorization Classes and Interfaces

The last logical grouping of classes deals with the authorization portion of JAAS. After a Subject has been authenticated, a client can obtain the permissions that are granted to the particular Subject and code source. The permissions granted to a Subject are configured in a JAAS policy. The javax.security.auth.PolicyFile class is a default file-based implementation provided by JAAS. This file is similar to the Java 2 policy file, which contains one or more grant statements, each of which can contain a set of permission statements.

Each grant statement specifies a codebase /codesigners/Principals triplet, including the permissions that have been granted to that triplet . What this means is that all the permissions will be granted to any code downloaded from the specified codebase and signed by the specified code signer, as long as the Subject running the code has all the specified principals in the Principal set. The following fragment shows a sample entry in the JAAS policy file:

 // example entry in JAAS policy file  grant CodeBase http://java.sun.com,      SignedBy "johndoe",      Principal com.sun.security.auth.NTPrincipal "admin"  {     Permission java.io.FilePermission "c:/winnt/stuff", "read, write";  };

Note

The CodeBase and SignedBy components are optional and, if absent, will allow any codebase and signer to match. This includes code that is unsigned as well.