User authentication and access control are important security measures for most Java applications, especially J2EE applications. The Java Authentication and Authorization Service (JAAS), the core API of J2SE 1.4 and 1.5, represents the new security standard. It provides a pluggable and flexible framework that allows developers to incorporate different security mechanisms and various security sources.

With the upcoming release of J2SE 1.5, which includes a lot of enhancements to cryptography, XML security, Public Key Infrastructure (PKI), Kerberos, and the federating identity, the JAAS will play a more important role in J2EE security implementations.

Overview of JAAS
Authentication
Authentication is the process of verifying that a user has the right to use identities established by the enterprise user registry. The authentication mechanism of JAAS is built on a set of pluggable modules (see Figure 1). JAAS allows different authentication models to be plugged in at runtime. The client applications always interact with JAAS through the LoginContext object.

The authentication process typically involves the following steps:
1.  Create a LoginContext object. The LoginContext looks up the configuration file to determine which LoginModule to use. Also, optionally, you can pass a CallbackHandler to the LoginContext.
2.  Perform authentication by calling the login method of LoginContext, which loads the predefined LoginModule to check if the user can be authenticated.
3.  Associate principals and credentials with the Subject if the user is authenticated.
4.  Or throw a LoginException in case login failed.
5.  Use the logout method of LoginContext to log out.

The login in JAAS is a two-phase process. The first phase is the "login" phase (as described in step 2). The only task in this phase is authentication. Once the process successfully passes this phase, the authentication process enters the "commit" phase (step 3) in which the commit method of LoginModule is called to associate the relevant principals and credentials with the Subject.

A Subject in JAAS represents an authenticated entity, such as a person or device. It contains a set of principals and security-related attributes such as a password and cryptographic keys. In the JAAS architecture, the Subject, along with the Permission, plays an important role in the authorization process.

Of all the authentication modules, the LoginModule is the interface to a particular authentication mechanism. Although the LoginModule never gets called directly by the client application, it provides a particular type of authentication via a pluggable module, which implements the authentication algorithm and determines how the actual authentication is performed. Sun provides a few default LoginModule implementations, such as JndiLoginModule, Krb2LoginModule, UnixLoginModule, and NTLoginModule under the package of sun.com.security.auth.module. Since the JAAS login architecture is extensible, you can pretty much "plug in" any LoginModule just by specifying which LoginModule to use in the configuration file. An example of a configuration file looks like this:

MySample {
com.sample.module.MyLoginModule required debug=true;
};

Here MySample is the name of the login context, which is passed into the LoginContext constructor when you create a new LoginContext to start the authentication process, followed by the configuration block. The block informs JAAS about the loginModule that should be used to perform authentication during the login. In addition to the LoginModule, any options to that LoginModule can also be specified here.

During the login step, the CallbackHandler is used by LoginModule to communicate with the user to obtain authentication information. The CallbackHandler handles three types of Callbacks: NameCallback, which prompts the user for a user name; PasswordCallback, which prompts for a password; and TextOutputCallback, which reports any error, warning, or other messages sent to the user.

Authorization
Authorization is the process of determining whether an authenticated user is permitted to perform some actions, such as accessing a resource. The process is policy-based since JAAS is built on the existing Java security model. The policy configuration file essentially contains a list of entries, such as "keystore" and/or "grant". The grant entry includes all the permissions granted for the authenticated codes or principals to do the security-sensitive operations, for instance, accessing a particular Web page or local file. JAAS supports principal-based policy entry. Permissions can be granted in the policy to specific principals.

The basic format of a grant entry looks like this:

grant Codebase "codebase_URL" Signedby "signer_name,"
Principal principal_class_name "principal_name",
Principal principal_class_name "principal_name",
S {
permission permission_class_name "target_name", "action",
permission permission_class_name "target_name", "action",
S
}

In the JAAS architecture, the Policy object represents the system security policy for a Java application environment and there's only one Policy object in effect at any time according to the Java 2 SDK document. The default implementation of Policy is sun.security.provider.PolicyFile, in which the policies are specified within one or more policy configuration files.

Once the user is authenticated, the authorization takes place via the Subject.doAs method, or the static doAsPrivileged method from Subject class. The doAs method dynamically associates the subject with the current AccessControlContext and then invokes the run method to execute the action, which causes the security checks. The permission check process goes through the following steps illustrated in Figure 2:

1.  Invoke Subject.doAs (or doAsPrivileged).
2.  Call SecurityManager.checkPermission or other check methods to check the permission.
3.  The SecurityManager delegates the check to the AccessController.
4.  The AccessController ensures the relevant AccessControlContext contains sufficient permissions for the action to be taken.
5.  The SecurityManager updates the current AccessControlContext with the permissions granted to the subject via the Policy from the policy file.

If the required permission to a specific principal is granted, the operation will be allowed. Otherwise, an AccessControlException will be thrown.

Like the LoginModule, the Policy is also a pluggable module. You can hook up other Policy implementations by changing "policy.provider=sun.security.provider.PolicyFile" in the java.security properties file to a value of the Policy class you want to use.

Extend JAAS
JAAS is built on top of the existing Java security model, which is CodeSource-based, and the plaintext format policy file implementation. This may not be enough for the enterprise application. You may want to use custom security repositories with JAAS, such as LDAP (lightweight directory access protocol), database, or another file system. It can be done by writing your own customized modules, thanks to the JAAS pluggable feature. However, this would require a good understanding of the modules and processes involved in JAAS, and you need to do a lot of coding to override the proper classes and take care of both the configure and policy files.

Ideally, we'd like to able to extend JAAS in an easier way so whenever a custom security repository or different access control mechanism changed or needed to add, you could just develop and plug in the different small modules (namely, the adapters) to accommodate these new changes or requirements, and best of all, without having to understand or know the details of the JAAS process. Also, we would like to be able to make this change simply by changing a configuration file. Another goal is that our JAAS extension component could be used in different J2EE applications - stand-alone or Web. Figure 3 outlines the design of our JAAS extension component.

Our JAAS extension component takes advantage of the JAAS pluggable architecture by implementing our customized LoginModule and Policy modules. In these modules, we delegate the data requests to the adapters. Each of these adapters is isolated to simple tasks such as data retrieval, so you can rapidly develop different adapters for different security repositories or algorithms instead of trying to implement different LoginModule or Policy modules, which are far more complex and require more effort.

You can download the complete source code from below.

AuthLoginModule
The AuthLoginModule class is our customized LoginModule implementation. The LoginModule is a pluggable component in the JAAS authentication process and serves two purposes:
1.  Authenticate the user.
2.  Update the Subject with relevant principals and credentials if authentication succeeded.

The LoginModule has five methods to implement. Let's look at the login () method. This method is called to authenticate the Subject and basically does two things:
1.  Obtains the user name and password. Typically, the LoginModule invokes the handle method of the CallbackHandler to get the user name and password.
2.  Verifies the password against the one in the data source.

The LoginModule retrieves the username and password from the Callbacks, which, by default, expect some sort of user interaction. This is fine for a simple demo program or on the command line, but it may not be practical for a J2EE application. For instance, for most Web applications, the user name and password will typically be read from a form. In this case, using JAAS authentication will be difficult. Considering we don't use LoginModule directly, the solution is to implement a customized CallbackHandler, which accepts a username and password and then delivers them to the LoginModule so it doesn't need to prompt the user for the information. Here's how the user information got passed from the JSP or servlet:

String userName = request.getParameter ("user");
String password = request.getParameter("password");
LoginContext context = new LoginContext ("MySample",
new AuthCallbackHandler (userName, password));

In the "commit" phase, the AuthloginModule retrieves the relevant information from the LoginSourceAdapter and associates them with the Subject.

LoginSourceAdapter
The LoginSourceAdapter is an interface of source adapter for the authentication. It has four methods for required implementations:
1.  void initialize (Hashtable parameters): The initialize method is called to initialize the adapter with the relevant parameters. The method is called immediately after object creation and prior to any calls to other methods.
2.  boolean authenticate (String userName, char[] password): The authenticate method is called to authenticate the user.
3.  String[] getGroupNames (String userName): The getGroupNames method is called to get the relevant principal information after authentication succeeded.
4.  void terminate (): This method is called when the logout method of LoginModule is invoked. It gives the adapter a chance to do some clean-up work.

The argument for the initialize method is the collection of a key-value pair. It could be the parameters for database connectivity, such as driver, URL, user ID, and password, or other information required for your adapter. You can specify these parameters in the configuration file, which I'll discuss later.

AuthPolicy
Under the JAAS architecture, the security policy is handled by the java.security.Policy class, which establishes the various Permissions granted to a particular CodeSource or Principal. As discussed in the previous section, the default implementation is sun.security.provider.PolicyFile. The PolicyFile uses the plaintext file to establish the mapping between permissions and CodeSource, which may not be good enough for the enterprise application. A centralized system such as a relational database for supporting role-base security would be better.

Obviously, to extend JAAS authorization to handle the different security schemes from different sources, we need to write our own Policy implementation.

The steps to create a customized Policy implementation are: