Login configuration for Java Authentication and Authorization Service

Login configuration for JAAS

+
Search Tips | Advanced Search

Java Authentication and Authorization Service (JAAS) is an authentication API that replaces the CORBA programmatic login API.
WAS extensions include...
com.ibm.websphere.security.auth.WSSubject:
Extends the JAAS authorization model to J2EE resources.
You can configure JAAS login in the console or by using the scripting functions and store this configuration in the WAS configuration API. However, WAS 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 WAS configuration API and the plain text file format, the one in the WAS 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 ND 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 WAS 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 WAS configuration repository. An application can define a new JAAS login configuration in the console and persist the data in the configuration repository that is stored in the WAS configuration API. However, WAS 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 WAS 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 WAS 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 Network Deployment installation.

Proxy LoginModule
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. WAS 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.
Do not remove or delete the predefined JAAS login configurations...

ClientContainer
WSLogin
DefaultPrincipalMapping

Deleting or removing them can cause other enterprise applications to fail.
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 WAS implementation permits the definition of the login configuration in both the WAS configuration API security document and in a JAAS configuration file, where the former takes precedence. JAAS login configurations are defined in the API security document for WAS configuration for applications to use. To access the configurations...

Click...
Security | Secure administration, applications, and infrastructure | Java Authentication and Authorization Service | Application logins

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 WAS client container.
The DefaultPrincipalMapping module defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WAS user identity to a set of user authentication data (user ID and password) for the specified back-end enterprise information system.
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 appservers. An appserver restart is required for the changes to take effect at runtime 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 subdirectory of the root directory under which WAS is installed. Changes made to the wsjaas.conf file are used only by the local appserver and take effect after the appserver restarts. The JAAS configuration in the WAS 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 WAS configuration API security document.
The 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.

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 runtime for WAS. The sample demonstrates the following technology:

J2EE Java Authentication and Authorization Service (JAAS)
JAAS for WAS
WAS security

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

Related tasks
Configure programmatic logins for Java Authentication and Authorization Service