Use external security managers in a cluster
General
Perform any configuration for an external security manager after you have completed all other setup, including ensuring that the WebSphere Portal cluster is functional.
When setting up security in a cluster to use an external security manager, perform the security configuration on each node in the cluster, as described in the following topics:
If you make any changes to the external security manager configuration after initially setting it up, first make the changes in wkplc_comp.propreties on the primary node of the cluster.
If additional nodes exist in the cluster, ensure that any changes you make to the wkplc_comp.properties file on the primary node are propagated to the wkplc_comp.properties file on other nodes in the cluster.
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 that the values for...
- wp.ac.impl.JunctionHost
- wp.ac.impl.JunctionPort
...are set to the backend server host name and port number you are using for your Web server.
Tivoli Access Manager
Run...
validate-pdadmin-connection
on each node in the cluster.
If the task fails, run the run-svrssl-config task.
The parameter...
wp.acc.impl.PDServerName
...in wkplc_comp.properties represents an individual configured AMJRTE connection to Tivoli Access Manager.
Each node in the cluster must have a unique value for wp.acc.impl.PDServerName before running the run-svrssl-config task.
Ensure that the WebSEAL Trust Association Interceptor (TAI) parameters are the same on each node in the cluster. If you run a configuration task at a later time that overwrites the WebSEAL junction, the WAS TAI properties are not automatically updated, so manually ensure that all nodes are using the same parameters.
The file location specified by the property...
wp.ac.impl.PDPermPath
...in the wkplc_comp.properties file indicates the location of the Tivoli 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.
Ensure that the value of the property...
wp.ac.impl.PDPermPath
...on each node corresponds to the location of the PdPerm.properties file.
This value can be set globally for all cluster members by using the configURL property, accessed in the deployment manager administrative console...
- WAS v6.1...
Security | Secure administration, applications, and infrastructure | Web Security | Trust Association | Interceptors | com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus | Custom Properties
- WAS v7.0...
Security | Global security | Java Authentication and Authorization Service | Application logins | Portal_Login | com.tivoli.mts.PDLoginModule | Custom properties
To ensure that the location of the PdPerm.properties file is properly specified, use one of the following approaches:
- If your nodes are all on UNIX platforms, use the UNIX link command (ln) to ensure the value for configUrl resolves on each node
- If the configURL parameter is not set in the administrative console, the default location is relative to the JAVA_HOME system property under the following path:
java_home/jre/PdPerm.properties
Make sure the wp.ac.impl.PDPermPath parameter for each node is set to this relative location before running the run-svrssl-config task, and completely remove the configURL property from the PDLoginModule custom properties.
Parent topic:
Cluster