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 is problematic and causes undesirable effort. 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 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 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; } });
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.
Two JAAS login configurations are defined in the WebSphere configuration API 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 (EIS). 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 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.
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 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 Java Authentication and Authorization Service (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.