Java Authentication and Authorization Service

Java and J2EE technology today is being used in large-scale, multi-user environments. This requires the ability to deal with multiple users concurrently, as well as handle their credentials, privileges, and identities in a consistent, manageable fashion. The Java Authentication and Authorization Services (JAAS) provides a framework and a standard API for user authentication, privilege management, and credential verification for the Java 2 and J2EE platforms. This section provides an overview of JAAS and its importance in securing enterprise applications.

In the Java platform, security policies can place fine-grained access control upon protected resources by verifying the identity of code source and who signed it. However, this model lacks enforcing control based on the user who runs the code. The code-centric model is important for executing code that is downloaded from other sources, as is common in browser-based applications. However, most applications are used in a multi-user environment and serve the needs of a wide audience with different levels of access privileges. JAAS complements the code-centric model by providing user-based authentication and authorization on top of the existing Java security model.

Subjects, Principals, and Credentials

In JAAS, a user or a computing service that desires to access protected resources or other protected computing services is represented as a subject. A subject interacts with a computing service using an identifier and will typically have a unique identifier with each service it interacts with. The JAAS specification calls this identifier a name. The term principal represents a name associated with a subject. A subject therefore comprises a set of principals as shown here:

 public interface Principal {     public String getName(); } public final class Subject {     public Set getPrincipals() { } } 

During the authentication process, a user or a computing service (subject) presents some form of evidence to another computing service (another subject) to prove its identity. The credentials provided during authentication may be userid/password and/or digital certificates, signed data, and so on. The JAAS security model takes into account that most services rely on named principals to access protected resources. Principals are associated with a subject once it successfully authenticates to a service.

Services that implement a conventional access control mechanism define a set of protected resources that may be accessed by a named principal. Principals in large-scale enterprise applications may use verifiable public key as identifier to ensure a unique, indisputable identity. In addition to principals, services may also require the subject to present added security-related attributes that may include password, PIN, public key certificates, and so on, as part of the request to access the service. These attributes are known as credentials in the JAAS framework and are typically used for SSO operations. JAAS credentials can be any type of object. Therefore, existing and third-party implementation may be plugged into the framework. Credential implementation may reference data that may physically reside on a separate server or even in hardware devices like smart cards. A credential implementation may also delegate to third parties using its own delegation protocol.

JAAS credentials are of two types: public and private. Public credentials include a subject's public identity attributes like PKCS certificates that are accessible without requiring any permission. Private credentials include a subject's private security-related attributes such as PCKS private keys, password, and so on, that have access controls. Please refer to the JAAS API for further details on the Subject class.

Authentication

Each service may have an authentication mechanism that is specific to it. Therefore the security-related attributes required by each service may be different. The JAAS framework supports a flexible architecture that allows the plugging in of different authentication services (called LoginModules) to meet the security requirements of an application. This architecture creates a loose coupling between the applications and the authentication services, thus enabling modification or replacement of authentication services without affecting the existing applications.

JAAS authentication framework is based on pluggable authentication module (PAM) framework and therefore supports the notion of stacked LoginModules. The JAAS LoginContext class represents a Java implementation of the PAM framework as shown here:

 public final class LoginContext {     public LoginContext(String name) { }     public void login() { }     public void logout() { }     public Subject getSubject() { } } public interface LoginModule {     boolean login();     boolean commit();     boolean abort();     boolean logout(); } 

The LoginContext consults a configuration file to determine the list of configured LoginModules. A sample configuration file that identifies the LoginModule(s) is shown here:

 GreaterCauseModules {com.gc.security.donor.DonorLoginModule required;} 

Note the use of the required flag in the configuration file. Other possible values are Requisite, Sufficient, and Optional. These flags control the overall behavior of the authentication process. More information about these flags is available at http://java.sun.com/j2se/1.4.1/docs/api/javax/security/auth/login/Configuration.html.

The LoginContext is instantiated as follows:

 LoginContext lc = new LoginContext ("GreaterCauseModules",     new myCallbackHandler()); 

Objects implementing the CallbackHandler interface are used for performing the user interaction for obtaining the credentials required for successful authentication. This is because there are various ways of communicating with a user, and we need to keep the LoginModule(s) independent of the different types of user interactions.

JAAS performs the authentication steps in two phases:

• In the first phase, the LoginContext's login method invokes the login method of each LoginModule specified in the configuration file. The login method of each LoginModule performs the authentication (for example, prompting/challenging the user for username and password). The LoginModule's login method will return true or false (indicating success or failure, respectively), or it may throw a LoginException. In case of a failure, if an application decides to retry the authentication, then phase 1 is repeated.

• In the second phase, if the LoginContext's overall authentication succeeded, then the commit method on each configured LoginModule is invoked. The commit method of the LoginModule will check its internal state to ensure if its own authentication succeeded. Once it is verified that both the overall LoginContext's authentication and the LoginModule's authentication has succeeded, then the relevant principals (authenticated identities) and credentials are associated with the subject.

Authorization

JAAS authorization is accomplished by enforcing the appropriate access controls on the principals associated to the subject during the authentication process. Services based on the JAAS access control model define a set of protected resources and the means through which principals may access them. The JAAS policy is built on top of the Java 2 codesource-based security policy, forming a complete authorization scheme for the Java 2 runtime system. The following code snippet is a sample principal-based policy entry supported by JAAS:

 grant Codebase "http://www.gc.com", Signedby "gcadmin",    Principal com.gc.Principal "pHolmes" {       Permission com.gc.siteAdmin.AccessPermission "administrator"             } 

This example grants code loaded from the remote resource "http://www.gc.com", that has been digitally signed by "gcadmin", and executed by "pHolmes" permissions to administer the site. To be executed by "pHolmes", the subject associated with the current access control context (explained later in this section), must contain a principal of class com.gc.Principal, whose getName function returns "pHolmes".

Roles are treated as "named" principals by JAAS. Access controls can thus be applied to roles just like to any other principal, as shown in the following code snippet:

 grant Codebase "http://www.gc.com", Signedby "gcadmin",    Principal com.gc.Role "administrator" {       Permission com.gc.siteAdmin.AccessPermission "administrator"             } 

The JAAS authorization framework also allows for the Principal class in a particular policy entry to programmatically determine if the principal is "implied" by a given subject. In this scenario, the Principal class (specified in the policy entry) "implements" the PrincipalComparator, whose implies method is invoked when permissions are determined for a subject.

 Public interface PrincipalComparator {    boolean implies (Subject subject); } 

Role hierarchies may be realized in this manner where a specific role (such as com.gc.Role) implements the PrincipalComparator interface and returns "true" if a specified subject contains an "administrator" role principal.

Associating a Subject with an AccessControlContext The java.lang.SecurityManager is consulted any time an untrusted code attempts to access protected resources. To determine whether the subject has sufficient authority to access a protected resource, the SecurityManager delegates to java.security.AccessController, which ensures that the AccessControlContext contains sufficient permission to allow access to the resource. JAAS dynamically associates an authenticated subject to AccessControlContext by providing a Subject.doAs method.

After a service performs user authentication, and before protected resources can be accessed, the service can associate the subject with the current access control context. This is done by preparing the operation to be performed as a java.security.PrivilegedAction and then calling the static Subject.doAs method and passing it an authenticated subject and a java.security.PrivilegedAction object. The doAs method associates the subject with the current access control context and then invokes the run method from the PrivilegedAction object. The action thus executes as the specified subject. When security checks occur during this execution, the SecurityManager queries the JAAS policy and updates the current AccessControlContext with the permissions granted to the subject and the executing codesource, and then performs its regular permission checks. When the PrivilegedAction run method finally completes, the doAs method removes the subject from the current AccessControlContext, and returns the result back to the caller.