Use external security managers in a cluster

Complete any configuration for an external security manager after completing all other setup.

The following considerations apply to all external security managers:

  • When setting up security in a cluster to use an external security manager, review and, if required, perform the security configuration on each node in the cluster.

  • If required, perform the security configuration on each node in the cluster, as described in Security Access Manager.

  • If you make any changes to the external security manager configuration after initially setting it up, first make the changes in the wkplc_comp.propreties on the primary node of the cluster. If additional nodes exist in the cluster, ensure that any changes made to wkplc_comp.properties on the primary node are propagated to wkplc_comp.properties on other nodes in the cluster.


Security Access Manager cluster considerations

  • Run the validate-pdadmin-connection task 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 that the parameter...

      wp.acc.impl.PDServerName

    ...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, edit wkplc_comp.properties on each node, and ensure that the values for properties...

      wp.ac.impl.JunctionHost
      wp.ac.impl.JunctionPort properties

    ...are set to the backend server host name and port number we are using for the Web server.

  • Ensure that the 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 WebSphere Application Server TAI properties are not automatically updated. 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.ISAMETai > Custom properties

    Note: 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.ISAMTrustAssociationInterceptorPlus > Custom properties

  • Enter the file location specified by the parameter...

      wp.ac.impl.PDPermPath parameter

    ...in wkplc_comp.properties. This property 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....

      Security > Global security > Web and SIP Security > Trust Association > Interceptors > com.ibm.ws.security.web.ISAMTrustAssociationInterceptorPlus > Custom properties

    Because the Deployment Manager 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 that the location of the PdPerm.properties file is properly specified, use one of the following approaches:

    • If the nodes are all on UNIX Linux platforms, use the UNIX Linux link command (ln) to ensure the value for com.hcl.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 file system to correctly reference the file.


eTrust SiteMinder cluster considerations

Ensure that we have installed and validated 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 topic: Cluster considerations