and Authorization Service

Java Authentication and Authorization Service (JAAS) is a new feature in WAS. JAAS is WAS strategic API for authentication that replaces the Common Object Request Broker Architecture (CORBA) programmatic login API.

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. We can configure JAAS login in the admin 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 an 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: We 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 admin 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 admin 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 WAS 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 ND 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. 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.

Tip: Do not remove or delete the predefined JAAS login configurations (ClientContainer, WSLogin and DefaultPrincipalMapping). Deleting or removing them can cause other enterprise apps 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...

1. Click...
   Security | Global security

2. Under Java Authentication and Authorization Service, click 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 (EIS).

See 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 admin console. The changes are saved in the cell-level security document and are available to all managed appservers. 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.

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 Java Authentication and Authorization Service (JAAS) login configuration entries in the admin 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.

See on how to access the form login sample, see Accessing the Samples (Samples Gallery).

---

 

Related tasks

Set programmatic logins for Java Authentication and Authorization Service