+

Search Tips   |   Advanced Search

ISAM integration as the JACC provider

Security Access Manager uses the Java Authorization Contract for Container (JACC) model in WebSphere Application Server to perform access checks.

ISAM consists of the following components:

For the run-time changes, ISAM 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 ISAM policy server by calling the respective ISAM API.

ISAM 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 that support JACC for more information about these interfaces.

To configure the ISAM client, we can use either the administrative console or wsadmin scripting. We can access the administrative console panels for the ISAM client configuration by clicking...

The Tivoli client must be set up to use the ISAM JACC Provider.

For more information about how to configure the ISAM client, see ISAM JACC provider configuration.

ISAM uses the RoleConfiguration interface to ensure that the authorization table information is passed to the ISAM 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 ISAM 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.

The user or group-to-role mapping is on the application level, not on the node level.

When WAS is configured to use the JACC provider for ISAM, it passes the information to ISAM to make the access decision. The ISAM policy implementation queries the local replica of the access control list (ACL) database for the access decision.

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.

The ISAM-provided PDLoginModule module can authenticate to WAS via:

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 ISAM policy object to use for access checking.

SWAM is deprecated in WAS v9.0 and will be removed in a future release.

When using Kerberos authentication

TAM loginModule creates the PDPrincipal without first going through the ISAM authentication process. Also when using Kerberos authentication mechanism and Security Access Manager, the ISAM policy is not enforced starting in WAS Version 7.0.


Related:

  • Authorization providers
  • JACC providers
  • JACC support in WAS
  • Enable an external JACC provider
  • Authorizing access to Java EE resources using ISAM
  • Propagating security policy of installed applications to a JACC provider
  • Interfaces that support JACC
  • Security authorization provider troubleshooting tips
  • IBM ISAM for e-business information center