Use external security managers in a cluster
Complete any configuration for an external security manager after completing all other setup. Review Systems requirements to ensure we are using a supported level of the external security manager software.
Perform the security configuration on each node in the cluster...
If we make changes to the ESM configuration after initially setting it up, first make the changes in wkplc_comp.propreties on the primary node, then propagate changes on other nodes in the cluster.
Security Access Manager cluster considerations
- Run validate-pdadmin-connection on each node in the cluster.
- If the validate-pdadmin-connection task fails, run the run-svrssl-config task before attempting to run validate-pdadmin-connection again. Note the wp.acc.impl.PDServerName parameter in wkplc_comp.properties represents an individually configured AMJRTE connection to Security Access Manager, and each node in the cluster must have a unique value for wp.acc.impl.PDServerName before running the run-svrssl-config task.
- For an external Web server, additional configuration is required before running any task to configure an external security manager with a WebSphere Portal cluster. Edit wkplc_comp.properties on each node, and ensure the values for the wp.ac.impl.JunctionHost and wp.ac.impl.JunctionPort properties are set to the backend server host name and port number we are using for the Web server.
- Verify the WebSEAL Trust Association Interceptor (TAI) parameters, found in wkplc_comp.properties, are the same on each node in the cluster. If we run a configuration task that overwrites the WebSEAL junction, the WAS TAI properties are not automatically updated. Therefore, manually ensure that all nodes are using the same parameters. To manually ensure the nodes are the same, use the dmgr console and go to...
Security | Global security | Web and SIP Security | Trust Association | Interceptors | com.ibm.sec.authn.tai.TAMETai | Custom properties
If we are still using the deprecated Trust Association Interceptors (TAIs) implementation, go to...
Security | Global security | Web and SIP Security | Trust Association | Interceptors | com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus | Custom properties
- Enter the file location specified by parameter...
...in wkplc_comp.properties. Indicates the location of the Security Access Manager AMJRTE properties file (PdPerm.properties). In a cluster composed of nodes with different operating systems, the location of the PdPerm.properties file might differ, depending on the node.
The value for wp.ac.impl.PDPermpath can be set globally for all cluster members. Use the property...
com.ibm.websphere.security.webseal.configURL
...accessed in the dmgr WebSphere Application Server. Go to...
Security | Global security | Web and SIP Security | Trust Association | Interceptors | com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus | Custom properties
Because the dmgr security configuration is not sensitive to each node's filesystem type, the value for the configURL property must be resolved on each node.
To ensure the location of the PdPerm.properties file is properly specified, use one of the following approaches:
- If the nodes are all on UNIX platforms, use the UNIX link command (ln) to ensure the value for 0.om.ibm.websphere.security.webseal.configURL resolves on each node.
- If the PdPerm.properties file location differs on each node and the cluster consists of different platforms, this property can accept a WebSphere Application Server variable to establish a location on each node's filesystem to correctly reference the file.
eTrust SiteMinder cluster considerations
Install and validate the eTrust SiteMinder binaries on each node in the cluster.
If we are only using eTrust SiteMinder for authentication, install and validate the Application Server Agent.
If we are using eTrust SiteMinder for authentication and authorization, both the Application Server Agent and the SDK must be installed and validated.
Parent Cluster considerations