Tivoli Access Manager integration as the JACC provider
Tivoli Access Manager (TAM) uses the Java Authorization Contract for Container (JACC) model in WAS to perform access checks. It consists of the following components.
- Run time
- Client configuration
- Authorization table support
- Access check
- Authentication using the PDLoginModule module
TAM run-time changes that are used to support JACC
For the run-time changes, TAM implements the PolicyConfigurationFactory and the PolicyConfiguration interfaces, as required by JACC. During the application installation, the security policy information in the deployment descriptor and the authorization table information in the binding files are propagated to the Tivoli provider using these interfaces. The Tivoli provider stores the policy and the authorization table information in the TAM policy server by calling the respective TAM APIs.
TAM also implements the RoleConfigurationFactory and the RoleConfiguration interfaces. These interfaces are used to ensure that the authorization table information is passed to the provider with the policy information. See Interfaces used to support JACC for more information about these interfaces.
TAM client configuration
The TAM client can be configured using either the administrative console or wsadmin scripting. The administrative console panels for the TAM client configuration are located under the Security center panel. The Tivoli client must be set up to use the Tivoli JACC provider.
For more information about how to configure the TAM client, see TAM JACC provider configuration.
Authorization table support
TAM uses the RoleConfiguration interface to ensure that the authorization table information is passed to the TAM provider when the application is installed or deployed. When an application is deployed or edited, the set of users and groups for the user or group-to-role mapping are obtained from the TAM server, which shares the same LDAP server as WAS. This sharing is accomplished by plugging into the application management users or groups-to-role administrative console panels. The management APIs are called to obtain users and groups rather than relying on the WAS-configured LDAP registry.
In a Network Deployment (ND) environment, the user or group-to-role mapping is on the application level, not on the node level.
Access check
When WAS is configured to use the JACC provider for TAM , it passes the information to TAM to make the access decision. The TAM policy implementation queries the local replica of the access control list (ACL) database for the access decision.
Authentication using the PDLoginModule module
The custom login module in WAS can do the authentication. This login module is plugged in before the WAS-provided login modules. The custom login modules can provide information that can be stored in the Subject. If the required information is stored, no additional registry calls are made to obtain that information.
As part of the JACC integration, the TAM-provided PDLoginModule module is also used to plug into WAS for both LTPA and SWAM authentication. The PDLoginModule module is modified to authenticate with the user ID or password. The module is also used to fill in the required attributes in the Subject so that no registry calls are made by the login modules in WAS. The information that is placed in the Subject is available for the TAM policy object to use for access checking.
See Also
Authorization in WAS
JACC providers
JACC support in WAS
Enabling an external JACC provider
Configuring a JACC provider
Propagating security policy of installed applications to a JACC provider using wsadmin scripting
Interfaces used to support JACC
Troubleshooting authorization providers
Related Information
IBM TAM for e-business 5.1
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.