Login configuration for Java Authentication and Authorization Service

WebSphere Application Server 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 Java 2 Platform, Enterprise Edition (J2EE) resources. You can configure JAAS login in the administrative console or by using the scripting functions and store this configuration in the WebSphere Application Server configuration API. However, WebSphere Application Server still supports the default JAAS login configuration format, a plain text file, which is provided by the JAAS default implementation. If duplicate login configurations are defined in both the WebSphere Application Server configuration API and the plain text file format, the one in the WebSphere Application Server 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 WebSphere Application Server Network Deployment product installation

  Due to a design oversight in JAAS 1.0, the javax.security.auth.Subject.getSubject method does not return the Subject that is associated with the running thread inside a java.security.AccessController.doPrivileged code block. This action can present an inconsistent behavior that is problematic. The com.ibm.websphere.security.auth.WSSubject extension provides a workaround to associate the Subject to the running thread. The com.ibm.websphere.security.auth.WSSubject extension expands the JAAS authorization model to J2EE resources.

  Why WebSphere Application Server has its own subject class: You can retrieve the subjects in a Subject.doAs block with the Subject.getSubject call. However, this procedure does not work if an AccessController.doPrivileged call is contained 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 either the administrative console or by using the scripting functions and stored in the WebSphere Application Server configuration repository. An application can define a new JAAS login configuration in the administrative console and persist the data in the configuration repository that is stored in the WebSphere Application Server configuration API. However, WebSphere Application Server still supports the default JAAS login configuration format that is provided by the JAAS default implementation. If duplicate login configurations are defined in both the WebSphere Application Server configuration API and the plan text file format, the one in the WebSphere Application Server configuration API takes precedence. The advantages to defining the login configuration in the WebSphere Application Server configuration API include:
  • 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 WebSphere Application Server 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 module cannot be loaded if the LoginModule class file is not in the application class loader or the class loader class path for the Java extension. WebSphere Application Server provides a proxy LoginModule module to load the JAAS LoginModule using the thread context class loader. You do not need to place the LoginModule implementation on the application class loader or the class loader class path for the Java extension with this proxy LoginModule module.

A system administrator determines the authentication technologies, or login modules, to use 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 WebSphere Application Server implementation permits the definition of the login configuration in both the WebSphere Application Server configuration API security document and in a JAAS configuration file, where the former takes precedence.

The WSLogin module defines a login configuration and the LoginModule implementation that can be used by applications in general.

The ClientContainer module defines a login configuration and the LoginModule implementation that is similar to the WSLogin module, but enforces the requirements of the WebSphere Application Server client container.

The DefaultPrincipalMapping module defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WebSphere Application Server user identity to a set of user authentication data (user ID and password) for the specified back-end enterprise information system (EIS). For more information about Java 2 Connector and the DefaultMappingModule, see the Java 2 Security section.

A new JAAS login configuration can be added and modified using the administrative console. 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 runtime and for the client container login configuration to be made available.

WebSphere Application Server also reads JAAS configuration information from the wsjaas.conf file under the properties subdirectory of the root directory under which WebSphere Application Server is installed. Changes made to the wsjaas.conf file are used only by the local application server and take effect after the application server restarts. The JAAS configuration in the WebSphere Application Server configuration API security document takes precedence over that defined in the wsjaas.conf file. A configuration entry in the wsjaas.conf is overridden by an entry of the same alias name in the WebSphere Application Server configuration API security document.

The Java Authentication and Authorization Service (JAAS) login configuration entries in the administrative console are propagated to the server runtime when they are created, not when the configuration is saved. However, the deleted JAAS login configuration entries are not removed from the server runtime. To remove the entries, save the new configuration, then stop and restart the server.