Section C.1. JAAS


C.1. JAAS

JAAS is a standard Java extension in J2SE 1.4, and it provides pluggable authentication that gives application designers a wide choice of security realms:

  • DBMS

  • Application Server

  • LDAP

  • Operating System (UNIX or Windows NT/2000)

  • File System

  • JNDI

  • Biometrics

JAAS supports single sign-on for an application. Rather than forcing the user to log in to a web site, and then log in again to a forum or a backend legacy system used by the application, JAAS coordinates all these steps into one central login event to help coordinate access to all systems that the user needs.

We chose JAAS as the basis for our authentication strategy because:

  • It provides a security context that covers the entire J2EE architecture from the web tier to the EJB tier.

  • It is application-server neutral.

  • It integrates with the Java 2 security model.

  • It is part of the J2SE 1.4 extension API.

  • It is more sophisticated than the other authentication mechanisms and provides more functionality.

  • It supports single sign-on by coordinating multiple security realms.

  • It addresses authorization in addition to authentication.

  • It provides good encapsulation for authentication and authorization, enabling an application to be independent of the underlying security mechanisms it uses.

C.1.1. JAAS Core Concepts, Classes, and Interfaces

Here are the key pieces of the JAAS framework and the roles that they play:


javax.security.auth.Subject

A Subject is a user ("John Smith") or outside entity ("Acme") that accesses the system. The Subject groups one or more Principals together and holds the user's credentials.


java.security.Principal

Although not officially part of the JAAS packages (javax.security.*), the Principal acts as a role for a Subject (user).


Credentials

A credential can be a password, certificate, or key that identifies the user to the system. The JAW Motors application uses passwords.


javax.security.auth.spi.LoginModule

A LoginModule wraps an underlying security realm and authenticates a user.


javax.security.auth.callback.Callback

A Callback holds user authentication credentials for the LoginContext.


javax.security.auth.callback.CallbackHandler

A CallbackHandler manages the Callbacks associated with the LoginContext. LoginModules interact with the CallbackHandler to get Callback objects.


javax.security.auth.login.LoginContext

A LoginContext coordinates the LoginModules and CallbackHandlers. An application uses the LoginContext to authenticate a user.


java.security.PriviligedAction, java.security.PrivilegedExceptionAction

These actions run code that's protected by a login. It is an implementation of the GoF Command pattern. The difference between these two interfaces is that PrivilegedExceptionAction runs code that can throw checked Exceptions, and PrivilegedAction does not run code that can throw checked Exceptions.

C.1.2. LoginContext

The JAAS LoginContext authenticates a user. The LoginContext instantiates the LoginModule (s) (that log the user into the security realm) based on the contents of the LoginModule Configuration file. By storing the LoginModule setup information in a configuration file, you can change the LoginModule(s) without modifying the application. The LoginContext invokes the LoginModule(s) for an application, and acts as the controller for the logon process. If the application accesses multiple security realms, the LoginContext coordinates the logon process across multiple LoginModule(s) (one per security realm).

C.1.3. LoginModule

The LoginModule logs a user/Subject into a security realm based on their username and password. A LoginModule could interact with an operating system, a database, JNDI, LDAP, or a biometric device like a retinal scanner or touch pad. Application developers normally don't need to know very much about LoginModules because the LoginContext invokes them on behalf of an application. Thus your code never interacts with LoginModules. To add or remove a LoginModule used by your application, you only need to modify the LoginModule Configuration fileyour code remains unchanged. This indirection enables an application to be independent of the underlying security mechanisms used

Although you could write your own LoginModule, doing so is usually unnecessary because of the abundance of quality third-party Open Source implementations available. You only need to know how to configure (in the LoginModule Configuration file) and deploy them for your particular runtime environment. If the Open Source LoginModule implementations don't provide all the functionality you need, you can either modify the code from that library or write your own LoginModule. Since this topic is outside the scope of this book, please see the JAAS LoginModule Developers' Guide (http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html) for further details.


Tagish

Tagish has a set of Open Source JAAS LoginModules released under the GNU (Lesser GNU Public License (LGPL) found at: http://free.tagish.net/jaas. The Tagish collection has the following LoginModules:

  • DBMS

  • File System

  • Windows NT/2000 domain


Sun Microsystems

Sun bundles several LoginModules with J2SE 1.4. However, they are in the com.sun.security.auth.module package and not officially part of J2SE 1.4 because they're Sun's implementation of the JAAS interfaces. Sun provides the following LoginModules:

  • Kerberos

  • Key Store

  • JNDI

  • Windows NT

  • UNIX


JBoss

JBoss provides several LoginModules with its distribution, including:

  • DBMS

  • File-based

  • Key Store

  • LDAP

  • External Client

We could easily configure the Tagish, Sun, or JBoss LoginModules and use them with the JAW Motors application. We chose the JBoss LoginModules because they're already bundled with JBoss and we don't need to configure any third party JARs. Even though we use LoginModules provided by JBoss, the application code remains vendor-neutral because:

  • The LoginModules are configured in an external configuration file.

  • The application code doesn't change if you use different LoginModules.

C.1.4. Callback

The Callback interface enables other JAAS components to retrieve user authentication information, such as usernames and passwords. The Callback implementations include:


ChoiceCallback

Enables LoginModules to display a list of choices and receive a response.


ConfirmationCallback

Allows LoginModules to ask for a confirmation like YES/NO or OK/CANCEL.


NameCallback

Enables LoginModules to ask for a username and receive a response.


PasswordCallback

Allows LoginModules to ask for a password and receive a response.

The external application uses the NameCallback to hold the username and the PasswordCallback to hold the password. As you'll see in the next section, we use these Callbacks a bit differently than the standard JAAS documentation, so it works in a command-line application.

C.1.5. CallbackHandler

The CallbackHandler is an interface that enables LoginModules to retrieve authentication information such as a username and password entered by the user. The CallbackHandler is the most confusing part of the JAAS API because its whole design premise is that you don't have user authentication data yet, and that the application needs to query the user for this information.

However, this type of user interaction flies in the face of the client application's design because the user already entered her username and password on the command line. The external client just needs to pass the user's data to the LoginContext. To make JAAS compatible with our application, we strip out the functionality that queries for a user name and password that you would see in a typical JAAS API tutorial. We'll implement a passive CallbackHandler that acts as a simple pass-through that holds only the username and password without querying the user for further information. The LoginModule(s) simply call the CallbackHandler's handle( ) method to retrieve the username and password that the user previously entered on the command line, as in Example C-1.

Example C-1. MyPassiveCallbackHandler.java
 import javax.security.auth.*; import javax.security.auth.callback.*; // Simple placeholder that stores userName and password. public class MyPassiveCallbackHandler implements CallbackHandler {     private String userName;     private String password;     public MyPassiveCallbackHandler(String userName,                                     String password) {         this.userName = userName;         this.password = password;     }     public void handle (Callback[  ] callbacks)         throws UnsupportedCallbackException {         for (int i = 0; i < callbacks.length; ++i) {             if (callbacks[i] instanceof NameCallback) {                 NameCallback nc = (NameCallback) callbacks[i];                 nc.setName(userName);             } else if (callbacks[i] instanceof                        PasswordCallback) {                 PasswordCallback pc =                            (PasswordCallback) callbacks[i];                 pc.setPassword(password.toCharArray(  ));             } else {                 throw new UnsupportedCallbackException(callbacks[i],                                   "Unrecognized Callback");             }         }     } } 

Once you get past this indirection, the rest of the JAAS API is straightforward. Figure C-1 shows the interactions in the API.

Figure C-1. JAAS sequence diagram


The application instantiates a LoginContext with the application name and an application-specific CallbackHandler (in our case, we instantiate MyPassiveCallbackHandler with a username and password entered from the login form). The LoginContext reads the LoginModule Configuration file and instantiates the LoginModule(s). The application then calls LoginContext's login( ) method, which in turn calls the login( ) method of each LoginModule. MyPassiveCallbackHandler returns the NameCallback (with the username) and PasswordCalback to each LoginModule when it calls MyPassiveCallbackHandler's handle( ) method.

C.1.6. JAAS LoginModule Configuration and Deployment

The JAAS LoginModule Configuration file configures the LoginModule(s) used by a J2SE application, specifies their runtime behavior, and optionally provides them with initialization parameters. The template in Example C-2 shows the format of a LoginModule Configuration file.

Example C-2. LoginModule Configuration file
 Application1 {     ModuleClassInvokedFirst Flag         ModuleOption1=value1         ...         ModuleOptionN=valueN     ;     ModuleClassInvokedLast Flag         ModuleOption1=value1         ...         ModuleOptionN=valueN     ; }; ... ApplicationN {     ... }; 

The LoginContext invokes the LoginModules in the order declared in the Configuration file. The Module Options are initialization parameters (with values) for each LoginModule.

C.1.7. LoginModule Configuration Flags

The Flag in the LoginModule Configuration file serves two purposes:

  • It gives the runtime behavior of each LoginModule.

  • It tells the LoginContext how to coordinate the LoginModule stack.

Here are the options available for LoginModule Configuration Flags:


Required

The LoginModule has to succeed. The LoginContext executes other LoginModules in the stack, regardless of the success or failure of a Required LoginModule. The overall authentication process fails if a Required LoginModule fails.


Requisite

The LoginModule must succeed. If it succeeds, the LoginContext continues executing other LoginModules. If it fails, the LoginContext immediately returns control to the caller without invoking any other LoginModules.


Sufficient

The LoginModule is not required to succeed. If it succeeds, the LoginContext immediately returns control to the application, and does not invoke the rest of the LoginModules in the stack. If it fails, the LoginContext continues executing other LoginModules.


Optional

The LoginModule does not have to succeed. The LoginContext executes other LoginModules in the stack, regardless of the success or failure of an Optional LoginModule.

Although JAAS provides a sophisticated set of options, we're going to be conservative and set our LoginModule(s) to Required because we don't want to allow the user to access sensitive portions of an application unless they successfully log on to all the security realms.

When filled in with real LoginModules and settings, the above LoginModule Configuration file template works in a J2SE environment when you add it your application's CLASSPATH. We use a J2SE-style LoginModule Configuration file when we create an external application client, but this won't work with most J2EE application servers. Refer to the Security chapter to see how to configure a server-side LoginModule on JBoss.



JBoss at Work. A Practical Guide
JBoss at Work: A Practical Guide
ISBN: 0596007345
EAN: 2147483647
Year: 2004
Pages: 197

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net