Implement Single Sign-on with JAAS

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:

Subject is populated with principal and credential information by the login module

CallBackHandler is used by the login module for capturing user credential information (such as username/password)

Shared state map will be used for passing user security information between login modules

Options are additional name/value pairs defined in the configuration file and are meaningful only for that particular login module.

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:

use_mapped_pass - Use the password-mapping scheme to get the actual password for this module. The module should not ask for the password if the user cannot be authenticated by the first password. Note that the process for decrypting passwords is left completely to the module.

try_mapped_pass - This attribute is the same as use_mapped_pass, except that if the primary password is not valid, the module should prompt the user for it.

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.