Login configuration for JAAS

 

+

Search Tips   |   Advanced Search

 

JAAS is WebSphere strategic API for authentication and it will replace the CORBA programmatic login APIs.

A system administrator determines the authentication technologies, or LoginModules, to be used for each application and configures them in a login configuration. The source of the configuration information (for example, a file or a database) is up to the current javax.security.auth.login.Configuration implementation. The WAS implementation permits the login configuration to be defined in both the WebSphere configuration API security document and in a JAAS configuration file where the former takes precedence.

JAAS login configurations are defined in the WebSphere configuration API security document for applications to use. To access the configurations, click...

Security | Global security | Authentication | JAAS configuration | Application logins

The WSLogin defines a login configuration and LoginModule implementation that may be used by applications in general. The ClientContainer defines a login configuration and LoginModule implementation that is similar to that of WSLogin but enforces the requirements of the WAS Client Container. The third entry, DefaultPrincipalMapping, defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WebSphere user identity to a set of user authentication data (user ID and password) for the specified back end enterprise information system (EIS).

New JAAS login configuration may be added and modified using Security Center. The changes are saved in the cell level security document and are available to all managed application servers. An application server restart is required for the changes to take effect at run time and for the client container login configuration to be made available.

WAS also reads JAAS Configuration information from the wsjaas.conf file under the properties sub directory of the root directory under which WAS is installed. Changes made to the wsjaas.conf file is used only by the local application server and will take effect after restarting the application server. Note that JAAS configuration in the WebSphere configuration API security document takes precedence over that defined in the wsjaas.conf file. In other words, a configuration entry in wsjaas.conf will be overridden by an entry of the same alias name in the WebSphere configuration API security document.

Note: The JAAS login configuration entries in the Security Center are propagated to the server run time when they are created, not when the configuration is saved. However, the deleted JAAS login configuration entries are not removed from the server run time. To remove the entries, save the new configuration, then stop and restart the server. WAS provides some extensions to JAAS:

  • com.ibm.websphere.security.auth.WSSubject:

    The com.ibm.websphere.security.auth.WSSubject API extends the JAAS authorization model to J2EE resources. One can configure JAAS login in the administrative console (or by using the scripting functions) and store this configuration in the WebSphere configuration API. However, WAS still supports the default JAAS login configuration format (plain text file) provided by the JAAS default implementation. If duplicate login configurations are defined in both the WebSphere configuration API and the plain text file format, the one in the WebSphere configuration API takes precedence. Advantages to defining the login configuration in the WebSphere configuration API include:

    • User interface support in defining JAAS login configuration
    • Central management of the JAAS login configuration
    • Distribution of the JAAS login configuration in a Network Deployment product installation

    Due to a design oversight in the JAAS 1.0, javax.security.auth.Subject.getSubject() does not return the Subject associated with the thread of execution inside a java.security.AccessController.doPrivileged() code block. This can present a inconsistent behavior that might cause problems. com.ibm.websphere.security.auth.WSSubject provides a work around to associate Subject to thread of execution. com.ibm.websphere.security.auth.WSSubject extends the JAAS authorization model to J2EE resources.

    Note: Why WAS has its own subject class: We can retrieve the subjects in a Subject.doAs() block with the Subject.getSubject() call. However, this procedure does not work if there is an AccessController.doPrivileged() call within the Subject.doAs() block. In the following example, s1 is equal to s, but s2 is null: 

    * AccessController.doPrivileged() not only truncates the Subject propagation, 
* but also reduces the permissions. It does not include the JAAS security 
* policy defined for the principals in the Subject.
Subject.doAs(s, new PrivilegedAction() {
  public Object run() {
    System.out.println("Within Subject.doAsPrivileged()");
    Subject s1 = Subject.getSubject(AccessController.getContext());
    AccessController.doPrivileged(new PrivilegedAction() {
      public Object run() {
      Subject s2 = Subject.getSubject(AccessController.getContext());
      return null;
    }
  });
  return null;
}
});

  • JAAS Login Configuration

    Can be configured in the administrative console (or by using the scripting functions) and stored in the WebSphere configuration repository. An application can define new JAAS login configuration in the Admin Console and the data is persisted in the configuration respository (stored in the WebSphere configuration API). However, WebSphere still support the default JAAS login configuration format (plan text file) provided by the JAAS default implementation. But if there are duplication login configurations defined in both the WebSphere configuration API and the plan text file format, the one in the WebSphere configuration API takes precedence. There are advantages to defining the login configuration in the WebSphere configuration API:

    • UI support in defining JAAS login configuration.

    • The JAAS configuration login configuration can be managed centrally.

    • The JAAS configuration login configuration is distributed in a Network Deployment installation.

  • Proxy LoginModule

    The Proxy.LoginModule is a proxy to the configured user or the system-defined module that the context class loader uses to load the module instead of the system class loader. The default JAAS implementation does not use the thread context class loader to load classes, the LoginModule could not be loaded if the LoginModule class file is not in the application class loader or the Java extension class loader classpath. Due to this class loader visibility problem, WebSphere provides a proxy LoginModule to load JAAS LoginModule using the thread context class loader. The LoginModule implementation does not have to be placed on the application class loader or the Java extension class loader classpath with this proxy LoginModule.

Note: Do not remove or delete the pre-defined JAAS Login Configurations (ClientContainer, WSLogin and DefaultPrincipalMapping). Deleting or removing them could cause other enterprise applications to fail.

 

Example

The samples gallery provides a JAAS login sample that demonstrates how to use JAAS with WAS. The sample uses a server-side login with JAAS to authenticate a user with the security run time for WAS. The sample demonstrates the following technology:

  • J2EE JAAS
  • JAAS for WAS
  • WAS security

The form login sample is component of the technology samples. For more information on how to access the form login sample, see Accessing the Samples (Samples Gallery).