JAAS login configuration

 

com.ibm.websphere.security.auth.WSSubject

Due to a design oversight in the JAAS 1.0, getSubject() does not return the Subject associated with the thread of execution inside a doPrivileged() code block. This can present a inconsistent behavior that is problematic and causes undesirable effort. WSSubject provides a work around to associate Subject to thread of execution. WSSubject extends the JAAS authorization model to J2EE resources.

One 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: 


// Not only truncate the Subject propagation, 
// also reduce the permissions, it does not includes 
// the JAAS security policy defined for the 
// principals in the Subject.

AccessController.doPrivileged() 
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

JAAS Login Configuration can be configured in Admin Console and stored in WebSphere Common Configuration Model (configuration repository). However, WebSphere still support the default JAAS login configuration format (plan text file) provided by the JAAS default implementation.

If there are duplication login configurations defined in both the WCCM and the plan text file format, the one in the WCCM takes precedence. There are advantages to define the login configuration in the WCCM:

  1. UI support in defining JAAS login configuration.
  2. The JAAS configuration login configuration can be managed centrally.
  3. The JAAS configuration login configuration is distributed in a Network Deployment installation.

 

Proxy LoginModule

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.

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. 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 WebSphere Application Server implementation permits the login configuration to be defined in both the WebSphere Common Configuration Model (WCCM) security document and in a JAAS configuration file where the former takes precedence.

Two JAAS login configurations are defined in the WCCM security document for applications to use. They may be found in the left navigation pane at Security > JAAS Configuration > Application Login Config: WSLogin and ClientContainer. 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 WebSphere Application Server 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 . For more information about Java 2 Connector and the DefaultMappingModule please refer to the Java 2 Security section.

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 appservers. An application server restart is required for the changes to take effect at run time.

WebSphere Application Server also reads JAAS Configuration information from the wsjaas.conf file under the properties sub directory of the root directory under which WebSphere Application Server is installed. Changes made to the wsjaas.conf file is used only by the local appserver and will take effect after restarting the application server. Note that JAAS configuration in the WCCM 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 WCCM security document.

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.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.