Migrating, coexisting, and interoperating – Security considerations

Use this topic to migrate the security configuration of previous WebSphere Application Server releases and its applications to the new installation of WebSphere Application Server.

Before you begin

This information addresses the need to migrate your security configurations from a previous release of IBM WebSphere Application Server to WebSphere Application Server Version 6.1 or later. Complete the following steps to migrate your security configurations:

  • If security is enabled in the previous release, obtain the administrative server ID and password of the previous release. This information is needed in order to run certain migration jobs.
  • You can optionally disable security in the previous release before migrating the installation. No logon is required during the installation.
  • [z/OS] If scriptCompatibility is false when migrating to WebSphere Application Server 6.1 on z/OS, any SSLConfig repertoire of type System SSL (SSSL) is converted to type JSSE. The exception is when the SSLConfig repertoire belongs to the daemon; the repertoire is not converted from type SSL to type JSSE in this case.

Procedure

Results

The security configuration of previous WebSphere Application Server releases and its applications are migrated to the new installation of WebSphere Application Server Version 6.1.

What to do next

If a custom user registry is used in the previous version, the migration process does not migrate the class files that are used by the standalone custom registry in the previous app_server_root/classes directory. Therefore, after migration, copy your custom user registry implementation classes to the app_server_root/classes directory.

If you upgrade from WebSphere Application Server, Version 5.x to WebSphere Application Server, Version 6.1, the data that is associated with Version 5.x trust associations is not automatically migrated to Version 6.1. To migrate trust associations, see Migrating trust association interceptors.

[iSeries] If the previous version instance is configured to enable secure connections using digital certificates that are signed by the Digital Certificate Manager (DCM) local certificate authority, those certificates must be renewed. For example, they must be renewed for the previous version instance, the WebSphere Application Server Version 6.1 profile, and all of the Secure Socket Layer-enabled clients and servers that connect to WebSphere Application Server. For more information, see SSL handshake failure using digital certificates signed by a Digital Certificate Manager (DCM) local certificate authority.

Vender-specific signer certificates, such as VeriSign and Thawte, are no longer included in the default truststore for WebSphere Application Server. To have these signer certificates available after migration, you must import them into the Application Server. To import signer certificates using the administration console, navigate to Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Add.

[iSeries] i5/OS *SYSTEM certificate stores for applications are deprecated in WebSphere Application Server Version 5. In WebSphere Application Server, you must migrate your applications to use Java keystores.

[iSeries] The os400.security.password.validation.list.object property is profile-dependent. If you are migrating from Version 5, see Migrating Java thin clients that use the password encoding algorithm for instructions on how to migrate your client configuration.

[z/OS] If you are migrating a Version 5.x or 6.0.x environment with Sync to OS Thread enabled to a Version 6.1 environment, you should be aware of the following migration considerations:
  • In addition to the application and configuration specifying the desire to use Sync to OS Thread that was required in earlier versions of WebSphere Application Server, the RACF administrator must also define a resource role in order for Sync to OS Thread to operate in later versions of WebSphere Application Server. A FACILITY class profile must be defined to allow or disallow the use of Sync to OS Thread. Also, an optional SURROGAT class profile can be used to further refine the use of Sync to OS Thread to particular authenticated users.

    See System Authorization Facility classes and profiles.

  • In Version 6.1 and later, a FACILITY class profile must be defined to enable trust applications. WebSphere Applications Server checks this FACILITY class profile during initialization to ensure that only authorized trusted applications are enabled. This FACILITY class profile expands the RACF administrator's role in ensuring that only authorized trusted applications are enabled.

    See System Authorization Facility classes and profiles.

For WebSphere Application Server Version 6.1.x, the default keystore type has changed from JKS to PKCS12. If the keystore Types are not changed to PKCS12 after the migration. you may encounter errors when accessing the keystore. The Type can be changed to PKCS12 using the administrative console. To change the Type, click Security > SSL certificate and key management > Manage endpoint security configurations > {Inbound | Outbound SSL_configuration_name}. Under Related Items, click Key stores and certificates and then the name of a specific keystore to show the details of that keystore. From this keystore details panel, change the Type to be PKCS12.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 1:23:07 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=tsecmigrate
File name: tsec_migrate.html