Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

---

 

Use external security managers in a cluster

If you are configuring security for IBM^® WebSphere^® Portal Express with an external security manager, review the additional considerations described in this section, depending on the external security manager that you are using. Perform any configuration for an external security manager after you have completed all other setup, including ensuring that the WebSphere Portal Express cluster is functional.

 

General considerations

The following considerations apply to all external security managers:

• When setting up security in a cluster to use an external security manager, ensure that you perform the security configuration on each node in the cluster, as described in the following topics:

  • IBM Tivoli^® Access Manager for e-business: Using Tivoli Access Manager with WebSphere Portal Express

  • Computer Associates eTrust SiteMinder: Using eTrust SiteMinder with WebSphere Portal Express

• If you make any changes to the external security manager configuration after initially setting it up, ensure that any changes you make to the wpconfig.properties file are propagated to the other nodes in the cluster. Changes to the wpconfig.properties file are not included as part of the cluster resynchronization process.

• If you are using an external Web server with WebSphere Portal Express, additional configuration is required before running any task to configure an external security manager with a WebSphere Portal Express cluster. Edit the wpconfig.properties file on each node, and ensure that the values for the WpsHostName and WpsHostPort properties are set to the host name and port number you are using for your Web server.

 

Tivoli Access Manager considerations

• Ensure that you 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 PDServerName property represents an individual configured AMJRTE connection to Tivoli Access Manager, and each node in the cluster must have a unique value for 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 WebSphere Application Server 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 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. You must 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 your 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 Tivoli Access Manager, set the value of WpsHostPort in the wpconfig.properties file to the SSL port (default of 443) before running either of the following Tivoli Access Manager 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 Tivoli Access Manager 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 you 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 Version 1.1 must be installed for these steps to work. Version 1.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 in the administrative console.

      2. Click on the name of the WebSphere Portal Express application server.

      3. Click Process Definition > Java Virtual Machine > Custom properties.

      4. Click New, and enter smasa.home for the name of the new property and ${SITEMINDER_TAI_LOCATION} for the property value.

      5. Click OK, and save your changes.

      6. Repeat these steps for each application server.

  When WebSphere Portal Express 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.

---