Use external security managers in a cluster

 

+
Search Tips   |   Advanced Search

 

 

Overview

When setting up security in a cluster to use an external security manager, perform the security configuration on each node in the cluster:

If changes are made to the external security manager configuration after initial setup, verify changes made to wpconfig.properties are manually propagated to the other nodes in the cluster. Changes to wpconfig.properties are not included as part of the cluster resynchronization process.

If you are using an external Web server, additional configuration is required. Edit wpconfig.properties on each node, and ensure that the values for...

...are set to the host name and port number used for the Web server.

 

TAM considerations

Execute the validate-pdadmin-connection task on each node in the cluster.

If validate-pdadmin-connection fails, execute the run-svrssl-config task before attempting to run validate-pdadmin-connection again.

Note that the PDServerName property represents an individual configured AMJRTE connection to TAM, and each node in the cluster must have a unique value for PDServerName before executing 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 TAI properties are not automatically updated, so manually ensure that all nodes are using the same parameters.

Note the file location specified by the PDPermPath property in the wpconfig.properties file. This property indicates the location of the 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 PDPermPath property 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 configURLName property, accessed in the deployment manager administrative console by clicking...

Security | JAAS Configuration | Application Logins | Portal_Login | JAAS Login Modules | 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 the nodes are all on UNIX platforms, use the UNIX link command (ln) to ensure the value for configUrlName resolves on each node

  • If the configURLName property 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 PDPermPath property for each node is set to this relative location before running the run-svrssl-config task, and completely remove the configURLName property from the PDLoginModule custom properties.

If you are creating an SSL junction in TAM, set the value of WpsHostPort in the wpconfig.properties file to the SSL port (default of 443) before running either of the following TAM configuration tasks: enable-tam-all, enable-tam-tai. After you have successfully run the task, change the value of WpsHostPort back to its initial value. If you do not reset the property after running the TAM tasks, subsequent attempts to access the portal by running the xmlaccess command (or configuration tasks that invoke it) will fail.

 

eTrust SiteMinder considerations

During the security configuration process with eTrust SiteMinder, the SMConfigFile property in the wpconfig.properties file is used to specify the location of the eTrust SiteMinder TAI configuration file. There are two approaches we can take when specifying the location of this file in a clustered environment:

  • Ensure that each node in the cluster has the same path to the TAI configuration file.

    eTrust SiteMinder TAI V1.1 must be installed for these steps to work. V1.0 does not support the use of a System property to specify the location of the eTrust SiteMinder TAI's WebAgent.conf file.

  • Define a WebSphere Application Server variable in the deployment manager administrative console. This variable can then be referenced in the custom System properties to be passed to each application server in the cluster. For example:

    1. Click...

      Environment | Manage WebSphere Variables

    2. Specify WP01 as the node in the scope field, click Apply, and then click New.

    3. Enter SITEMINDER_TAI_LOCATION as the variable name and the directory path where the configuration file is located on node WP01. such as...

      c:\netegrity\smwastai\

    4. Click OK.

    5. Specify WP02 as the node in the scope field, click Apply, and then click New.

    6. Enter SITEMINDER_TAI_LOCATION as the variable name and the directory path where the configuration file is located on node WP02, such as...

      /usr/netegrity/smwastai/

    7. Click OK.

    8. Repeat these steps for any other nodes in the cluster.

    9. Save the changes to update the deployment manager master configuration.

    10. Edit the wpconfig.properties file on each node, and update the SMConfigFile property with the variable information:

      SMConfigFile=WebAgent.conf

    11. For each application server, create a new custom property by completing the following steps:

      1. Click...

        Servers | Application Server | WebSphere_Portal | Process Definition | Java Virtual Machine | Custom properties | New

      2. Enter smasa.home for the name of the new property and...

        ${SITEMINDER_TAI_LOCATION}

        ...for the property value.

      3. Click OK, and save changes.

      4. Repeat these steps for each application server.

    When WebSphere Portal configuration tasks are run with this configuration, a server variable is generated in the custom properties of the JVM, which is evaluated and resolved at runtime on each node.

 

Parent topic:

Clustering and WebSphere Portal