Interoperating with previous product versions

IBM® WebSphere® Application Server inter-operates with the previous product versions. Use this topic to configure this behavior.

Before you begin

Interoperability is achieved using the z/OS® Secure Authentication Service (z/SAS) security mechanism for local OS and System Authorization Facility (SAF)-based authorization.

The current release of the Application Server distinguishes the identities of the user who acts as an administrator, managing the Application Server environment, from the identity of the user that is used for authenticating between servers. In prior releases, the user had to specify a server user ID and password as the user identity for authenticating between servers. In the current release of the Application Server, the server user ID is generated automatically and internally; however, the user can specify that the server user ID and password not be automatically generated. This option is especially important in the case of a mixed-release cell, where the server user ID and password are specified in a down-level version of the Application Server. In such a scenario, the user should opt out of automatically generating the server user ID and instead use the server user ID and password that is specified in the down-level version of the Application Server, in order to ensure backwards compatibility.

Interoperability is achieved only when the Lightweight Third Party Authentication (LTPA) authentication mechanism and a distributed user registry is used such as Lightweight Directory Access Protocol (LDAP) or a distributed Custom user registry. LocalOS on most platforms is not considered a distributed user registry (except on z/OS within the z/OS environment).

Important: z/SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.

1. Configure WebSphere Application Server Version 8.5 with the same distributed user registry (that is, LDAP or Custom) that is configured with the previous version.
   Make sure that the same LDAP user registry is shared by all of the product versions.
   1. In the administrative console, select Security > Global security.
   2. Choose an available Realm definition and click Configure.
   3. If SAF authorization is disabled, enter a Primary administrative user name.
      This identity is the user with administrative privileges that is defined in your local operating system. If you are not using the local OS ad the user registry, select the Server identity that is stored in the user repository, enter the Server user ID, and the associated password. The user name is used to log on to the administrative console when administrative security is enabled. WebSphere Application Server Version 6.1 requires an administrative user that is distinct from the server user identity so that administrative actions can be audited.

      Attention: In WebSphere Application Server, Versions 5.x and 6.0.x, a single user identity is required for both administrative access and internal process communication. When migrating to Version 8.5, this identity is used as the server user identity. You need to specify another user for the administrative user identity.
   4. Enter a Primary administrative user name.
      This identity is the user with administrative privileges that is defined in your local operating system. If you are not using the local OS ad the user registry, select the Server identity that is stored in the user repository, enter the Server user ID, and the associated password. The user name is used to log on to the administrative console when administrative security is enabled. WebSphere Application Server Version 6.1 requires an administrative user that is distinct from the server user identity so that administrative actions can be audited.

      Attention: In WebSphere Application Server, Version 6.0.x, a single user identity is required for both administrative access and internal process communication. When migrating to Version 8.5, this identity is used as the server user identity. You need to specify another user for the administrative user identity.
   5. When interoperating with Version 6.0.x or previous versions, you must select the Server identity that is stored in the user repository. Enter the Server user id and the associated Password.
2. Configure the LTPA authentication mechanism. Automatic generation of the LTPA keys should be disabled. If not, keys used by a previous release are lost. Export the current LTPA keys from WebSphere Application Server Version 8.0 and import them into the previous release or export the LTPA keys from the previous release into Version 8.0.
   1. In the administrative console select Security > Global security.
   2. From Authentication mechanisms and expiration, click LTPA.
   3. Click the Key set groups link , then click the key set group that displays in the Key set groups panel.
   4. Clear the Automatically generate keys check box.
   5. Click OK, then click Authentication mechanisms and expiration in the path on the Key set groups panel.
   6. Scroll down to the Cross-cell single sign-on section, and enter a password to use for encrypting the LTPA keys when adding them to the file.
   7. Enter the password again to confirm the password.
   8. Enter the Fully qualified key file name that contains the exported keys.
   9. Click Export keys.
   10. Follow the instructions provided in the previous release to import the exported LTPA keys into that configuration.
3. If you are using the default SSL configuration, extract all of the signer certificates from the WebSphere Application Server Version 8.5 common trust store. Otherwise, extract signers where necessary to import them into the previous release.
   1. In the administrative console, click Security > SSL certificate and key management.
   2. Click Key stores and certificates.
   3. Click CellDefaultTrustStore.
   4. Click Signer certificates.
   5. Select one signer and click Extract.
   6. Enter a unique path and filename for the signer.
      For example, /tmp/signer1.arm.
   7. Click OK. Repeat for all of the signers in the trust store.
   8. Check other trust stores for other signers that might need to be shared with the other server. Repeat steps e through h to extract the other signers.
   You can also import a signer certificate, which is also called a certificate authority (CA) certificate, from a truststore on a non-z/OS platform server to a z/OS keyring. the z/OS keyring contains the signer certificates that originated on the non-z/OS platform server. For more information, see Importing a signer certificate from a truststore to a z/OS keyring.
4. Add the exported signers to DummyServerTrustFile.jks and DummyClientTrustFile.jks in the /etc directory of the back-level product version. If the previous release is not using the dummy certificate, the signer certificate(s) from the previous release must be extracted and added into the WebSphere Application Server Version 8.5 release to enable SSL connectivity in both directions.
   1. Open the key management utility, iKeyman, for that product version.
   2. Start ikeyman.bat or ikeyman.sh from the ${USER_INSTALL_ROOT}/bin directory.
   3. Select Key Database File > Open.
   4. Open ${USER_INSTALL_ROOT}/etc/DummyServerTrustFile.jks.
   5. Enter WebAS for the password.
   6. Select Add and enter one of the files extracted in step 2.
      Continue until you have added all of the signers.
   7. Repeat steps c through f for the DummyClientTrustFile.jks file.
5. Verify that the application uses the correct Java™ Naming and Directory Interface (JNDI) name and naming bootstrap port for performing a naming lookup.
6. Stop and restart all of the servers.