ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Java vs. .NET Security, Part 4
Pages: 1, 2, 3, 4, 5

User Authentication: Other Mechanisms

Besides the standard web-based mechanisms, both platforms provide other means for authentication.



In .NET, Windows and Passport authentication are incorporated as separate entities via the corresponding modules. They both are used together with IIS, and require very little configuration in the application's configuration file.

WindowsAuthenticationModule relies on IIS to authenticate the caller, as shown in Figure 2, and attaches WindowsPrincipal object to the application context. This is the default provider for ASP.NET, and the easiest to use in pure Microsoft network environment, as it requires no additional application code.

<authentication mode="Windows">
</authentication>

Figure 2
Figure 2. ASP.NET Windows Authentication

PassportAuthenticationModule is a wrapper around the Passport SDK that creates a PassportIdentity object using Passport service and profile, as shown in Figure 3. This identity object provides access to the Passport profile and allows the encrypting/decrypting of authentication tickets. Most of the authentication details are handled by the ASP.NET framework; the developer can control the process by overloading the OnAuthentication handler.

<authentication mode="Passport">

</authentication>

Figure 3
Figure 3. ASP.NET Passport Authentication

In Java, JAAS serves as a general abstraction for providing authentication services to applications. JAAS relies on Pluggable Authentication Modules (PAM) in its operation to provide a flexible authentication framework. Administrators can add various implementations to the environment and modify its behavior and authentication method. The default PAM is username/password based; however, it is possible to use alternative schemas. In JDK 1.4, Sun provides implementations for the following login schemas via its LoginModule implementations: UnixLoginModule, NTLoginModule, JNDILoginModule, KeyStoreLoginModule, and Krb5LoginModule. Additionally, there exist implementations of SmartCard login modules by independent vendors; for instance, GemPlus.

A sample Java application, which demonstrates some of the discussed JAAS authentication techniques, can be found here.

In this section, only the authentication part of JAAS will be reviewed. Its operation is controlled by the LoginContext, which uses the Configuration class to retrieve the specified LoginModules. Those modules retrieve credentials with the help of provided Callbacks, although it is possible to use other means as well. There might be several LoginModules configured, and during the login process all of them are queried in turn, which is shown in Figure 4.

Figure 4
Figure 4. JAAS Login

The relationship among LoginModules is determined by the strategy configuration settings, which tells the system how to treat login failures in individual modules:

  • required: It must succeed for the overall login to succeed. However, LoginContext finishes querying other modules before aborting the process.

  • requisite: Same as required, but the login process stops if this module fails.

  • sufficient: Success of this module means that the overall process succeeds (provided that no requiredor requisite modules failed) and the login process stops.

  • optional: Just what it says; pretty much does not affect the login process.

JAAS introduces a couple of new permissions, javax.security.auth.PrivateCredentialPermission and javax.security.auth.AuthPermission, to guard access to the Subject, LoginContext, and Configuration classes. The code that works with JAAS classes will need to have them (especially AuthPermission) granted in java.policy. See the online Javadoc for details about their usage.

The following classes are used as part of JAAS authentication process:

  • javax.security.auth.login.LoginContext: Represents the PAM framework. This class is used by the server to access Configuration and use the specified LoginModule(s) to validate the passed user credentials. Once the login operation successfully finishes on all configured LoginModule(s) (using a two-phase commit process), the Subject is attached to the call context and is available for the application code.

    public final class LoginContext { 
      public LoginContext(String name);
      public void login(); // two phase process 
      public void logout();
      public Subject getSubject();//get the authenticated Subject 
    }
  • javax.security.auth.login.Configuration: Tells JAAS' LoginContext which LoginModule(s) are configured, and what the login strategy is. An alternative configuration provider implementation can be specified in the java.security file by setting the login.configuration.provider property.

    MyJAASConfig {
      UsernamePasswordLoginModule   requisite;
      CertificateLoginModule        sufficient;
    };

    The location of the configuration file is specified using the command-line option:

    java -Djava.security.auth.login.config==jaas.config MyJAASApp
  • javax.security.auth.spi.LoginModule: Represents a particular authentication type in an application -- for instance, password-based or RSA. During login, each of the configured modules is requested by the LoginContext object to authenticate the user's credentials. If the authentication succeeds (as configured in the JAAS), the login is committed, and a Subject is created; otherwise, the abort method is called.

    public interface LoginModule { 
      boolean login(); // 1st authentication phase 
      boolean commit(); // 2nd authentication phase 
      boolean abort(); 
      boolean logout(); 
      void initialize(Subject subject, CallbackHandler handler,
          Map sharedState, Map options);
    }
  • javax.security.auth.callback.Callback, javax.security.auth.callback.CallbackHandler: Used to gather all necessary credentials and report them back to the requesting module. Sun provides default implementations for several callbacks with the package, most importantly NameCallback, and PasswordCallback. Varying handlers may be used to gather and return the requested information; the ones supplied by default include DialogCallbackHandler for dialog-based, and TextCallbackHandler for command-line prompts.

Different user identities and roles are represented via Principals, added to the resulting Subject by the configured LoginModules during the commit phase, and removed during logout. Their credentials may also be added to that object, as well as any additional identification information.

public abstract class DemoLoginModule implements LoginModule {
  protected Subject m_subject;
  protected ArrayList m_principals = null;
  public boolean commit() throws LoginException {
    // Login succeeded, 
    // add demo Principals to the Subject.
    if (!(m_subject.getPrincipals().containsAll(
                                m_principals))) {
        m_subject.getPrincipals().addAll(
                                   m_principals);
    }		
    return ret;
  }
  public boolean logout() throws LoginException {
    // Need to remove our 
    // principals from the Subject.
    if (null != m_principals) {
      m_subject.getPrincipals().removeAll(
                                   m_principals);
      m_principals = null;
    }
    return true;
  }
}

The interaction of the various JAAS classes during initialization process is shown in Figure 5 below.

Figure 5
Figure 5. JAAS Initialization

Note: JAAS provides a flexible and versatile mechanism for adding authentication to any type of Java application.

Pages: 1, 2, 3, 4, 5

Next Pagearrow