ith the increasing use of distributed systems, users often need to access multiple resources to finish a single business transaction. Traditionally, users have had to sign on to all these systems, each of which may involve different usernames and authentication requirements. With the introduction of the single sign-on technique, users can login once and be authenticated for all systems involved in a given business transaction.

Although the single sign-on concept is appealing, implementing it is not at all easy because enterprise systems often have varying security requirements and a wide range of underlying technologies on which they are deployed. In Java environments, Java Authentication and Authorization Service (JAAS) has made implementation easier. JAAS, a significant enhancement to the Java security architecture, is an ideal tool for access control in a multi-user environment where users must be granted varying privileges. Unlike the standard JDK security model, which is code-source-based permission checking, JAAS controls access to resources with both code-source-based and user/role-based permission checking. Most importantly, the “pluggable” and stackable login module architecture that JAAS defines makes it instrumental in supporting legacy security implementations on different technologies and serves as a useful mechanism for implementing single sign-on.

Single sign-on can be implemented for applications that are deployed either locally or over a network. In the case of a network, after the user logs into the primary domain, an encrypted secure token is created and sent over the wire to other applications. In local networks, user credential data is exchanged directly between applications. Both deployment options share two key challenges: passing user credential information between involved domains and translating this information.

An enterprise application can be comprised of several Web applications, each of which may depend on different technologies and data stores to retrieve the user information it needs to authenticate the user and determine his or her privilege. If a business transaction crosses the Web application boundary, the user needs to log into each Web application and present similar credentials to each of the application authentication services.

This article demonstrates a single sign-on implementation for multiple Web applications based on JAAS. Specifically, it introduces an approach to achieving single sign-on between Web applications deployed on the same application server. (see Sidebar: Security Issues of JAAS Single Sign-on Implementation)The JAAS Authentication Framework
Before I get into the single sign-on implementation, let’s examine what’s under the JAAS hood. The JAAS framework is composed of two interdependent parts: an authentication part and an authorization part. The authentication part is used to determine the identity of the user, while the authorization part checks the permission of the authenticated user and controls resource access based on the user’s privileges.

A user has to be authenticated before he/she can access any sensitive resources. After the user is successfully authenticated, his/her principal is populated in the associated Subject class and the permissions granted to the principal are then checked by the authorization component.

Pluggable Authentication Module (PAM) Framework
The JAAS authentication framework is based on Pluggable Authentication Module (PAM). JAAS authentication is performed in a pluggable fashion that allows an application to add more authentication modules. Java applications can remain independent from underlying authentication technologies, and thus both legacy and new authentication technologies can be seamlessly configured without requiring modifications to the application itself.

The JAAS authentication framework allows applications to define any number of login modules in the configuration file. The JAAS framework invokes these login modules in the order they were specified. Applications can also specify a flag to each login module to indicate the relative importance of that module. The overall authentication depends on the combined results of these individual authentication modules.

PAM allows different Web applications to authenticate users against its own data store, be it an LDAP server, relational database, NT domain, or even a file. PAM is the feature that enables developers to implement single sign-on among Web applications deployed on the same application server.

LoginModule
The LoginModule interface gives developers the ability to implement different kinds of authentication technologies that can be plugged under an application. For example, one type of LoginModule may perform a username/password-based form of authentication. Other LoginModules may interface to hardware devices such as smart cards or biometric devices.

The ability to pass optional share information between login modules is the key feature I employ to achieve single sign-on among Web applications. User credential information can be shared using this option and since it is not sent across the network, there is no need for extra effort to maintain the integrity and security of the credential information.JAAS Implementation of Single Sign-On for Multiple Web Apps
Now let’s get to the implementation of single sign-on based on JAAS for Web applications deployed on the same server. To make it easier for discussion, I use an LDAP-based login module as an example.

Login Configuration for Single Sign-On
When multiple Web applications are deployed on a single application server instance, usually each Web application authenticates users based on its own data store. One Web application may use a relational database to store user security information and another may use an LDAP server to authenticate users. The JAAS PAM architecture allows an enterprise application to define a stack of login modules, each of which is independent and communicates to its own data source. To achieve single sign-on, each Web application defines its own login module and all modules are stacked in a certain order in the login configuration file.

JAAS defines a configuration interface, which a user can implement to store configuration data in a file or a database. In this discussion, I assume a file-based login configuration and I use a Logistics enterprise application as an example. The Logistics enterprise application contains two Web applications: carrier Web application and shipper Web application. Carrier users log into the carrier Web application to report location and movement events for shipment and Shipper users log into the shipper Web application to query the delivery events of shipment.

If a 3PL (third-part logistics) uses this Logistics enterprise application, employees of the 3PL will need to log into both Web applications to maintain and query shipment status on behalf of both the carrier and shipper. To achieve single sign-on in this situation based on JAAS, the login configuration file needs to be defined as follows:

LogisticsEnterpriseApplication{   com.cysive.framework.security.ldap.LDAPLoginModule 
   required name=CarrierSecurityDomain;   com.cysive.framework.security.ldap.LDAPLoginModule 
   required name=ShipperSecurityDomain  useSharedState=true;};

Notice two LDAP login modules are defined: one for the carrier Web application and one for the shipper Web application. These two login modules may communicate to the same LDAP server or different ones, depending on the configuration (using name attribute to link to the particular configuration block) for the LDAP server. For single sign-on, the flags for both login modules are specified as required (other flags include optional, sufficient, and requisite), which means the user must be successfully authenticated by both LDAP servers.

Additionally, the attribute useSharedState is specified. If it is true, this LoginModule retrieves the username and password from the module’s shared state, using “javax.security.auth.login.name” and “javax.security.auth.login.password” as the respective keys. The retrieved values are used for authentication. The username and password are set into shared state by LoginContext before invoking the login method of the login module instance. The useSharedState attribute allows all login modules to share the user’s credential information, which is captured only once.

An XML-based Configuration for Login Module
When the login module communicates with the data store, be it a database or an LDAP server, it requires certain configurations for common or special attributes. Using the LDAP login module for example, it will at least know the hostname of the LDAP server. Depending on your implementation, you may need different configuration parameters. Listing 1 shows a sample configuration block for the two LDAP login modules defined in the previous sections.

This configuration needs to be loaded when the application server starts up so it can be shared by Web applications loaded later. I will not discuss each entry in detail but instead focus on the parts that are relevant to single sign-on.

While each block is being loaded, the initializer class is invoked. The initializer reads all the properties and registers them in the domain manager class with the name specified by the name attribute. The value of this name attribute is the same as the one specified in the login configuration file. This is how the login module entry is associated with its configuration block.

If the configuration is simple, you can even configure it when you define the login module in the configuration file, such as:

com.cysive.framework.security.ldap.LDAPLoginModule 
required DriverName="oracle.jdbc.driver.OracleDriver" 
InitialCapacity="0" MaxCapacity="10" Properties="user=cymbio;password=cymbio 
URL="jdbc:oracle:thin:@jtao1:1521:jtao1"; 	

However, if your initialization for a login module requires substantial setup, a separate initialization block is the preferred approach.

In the two sample LDAP initialization blocks, the carrier security domain configures the login module to talk to the carrier.cysive.com LDAP server while the shipper login module communicates with shipper.cysive.com. You can easily substitute one of them with a relational database login module if user security information is stored in a database.Passing Shared Security Token Between Login Modules
JAAS defines a LoginContext class, which provides a context for all login modules defined for an application. Its login method iterates through all login modules and calls each login module’s login method. It determines the overall authentication result by combining the results of the login method returned from each login module.

In the login method of LoginContext, each login module defined in the configuration file is instantiated and then is passed four parameters using the initialize method of the login module (See Listing 2, exception checking is omitted for smaller code).

The following are the four parameters the initialize method passes:

The shared state map parameter is key to implementing single sign-on. After the first login module captures the user credential information, such as user name and password, it puts the information into the shared state map and passes it to other login modules on the list. The other login module has an optional parameter specified (useSharedState=true), so it simply gets the shared security information back and authenticates against its own security data store. Listing 3 shows a code excerpt for the LoginModule that implements this (exception checking has been omitted to reduce the length of the code segment).

ReMapping of Security Information
Using a shared state map to pass security information between login modules to achieve single sign-on requires the user to have the same credential information across all domains. I could enforce the same username and password for all domains that involve single sign-on, but that may limit legacy security systems that have varying user name and password requirements. For example, different authentication mechanisms may have their own distinctive password requirements with regard to length, characters allowed, and so forth. These requirements make using the same username and password for multiple login modules problematic.

In their paper, “Making Login Services Independent of Authentication Technologies”, Vipin Samar and Charlie Lai proposed a mapping mechanism that solves this problem. This mapping enables the user’s primary password to be used for encrypting the user’s secondary passwords. Once the primary password is verified, the login module obtains the password by decrypting the mechanism-specific encrypted password with the primary password. It then authenticates it to its data store. How the password is encrypted depends completely on the module implementation. To use password mapping, Samar and Lai also suggest two more optional attributes be passed to the login module:

Shared Map Is Key
Single sign-on for multiple Web applications is useful when business transactions cross session context boundaries. The pluggable and stackable login module infrastructure provided by JAAS allows enterprise applications to authenticate users with different login mechanisms and technologies. Exchanging security information between login modules using the shared map is the key to implementing single sign-on.