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 9.0. 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.
If scriptCompatibility is false when migrating to WebSphere Application Server Version 9.0 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 SSSL to type JSSE in this case.

Tip: Be aware of the following additional migration requirements for security:

When migrating from WebSphere Application Server Version 7.x to Version 9.0, if you have a business need to preserve security audit logs from the older release you must first archive the security audit log files in Version 7.x. WebSphere Application Server does not support the migration of security audit log files from the older release to Version 9.0.
When migrating from WebSphere Application Server Version 7.x to Version 9.0 on a z/OS system, if you used a writeable System Authorization Facility (SAF) keyring setting on version 7.x make sure that writeable SAF is also enabled on the Version 9.0 system. Writeable SAF is a RACF® setting.
If your WebSphere Application Server Version 7.x environment is enabled for Kerberos, and you are migrating to Version 9.0 on a different machine, the keytab and configuration files for Kerberos must be at the same location on the Version 9.0 machine as on the Version 7.x machine or the configuration will not work.

Procedure

Migrate the appropriate product configuration.
You can migrate the base application server node, a deployment manager, and a federated node.
Use the First steps console to access the WebSphere Customization Toolbox, and run the Migration Management Tool.
1. Start the First steps console by launching the firststeps.bat or the firststeps.sh file.
  The firststeps command is located in the following directory:
  - ./app_server_root/profiles/profile_name/firststeps/firststeps.sh
  - app_server_root\profiles\profile_name\firststeps\firststeps.bat
2. On the First steps console panel, click WebSphere Customization Toolbox.
3. Open the Migration Management Tool.
4. Follow the instructions provided to complete the migration.
Follow the steps in Migrating product configurations.

Results

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

What to do next

You must migrate any custom class files that are not migrated.

[z/OS] If you are migrating a Version 6.1 environment or earlier with System Authorization Facility (SAF) authorization enabled, be aware that the term describing the string that is prepended to the EJBROLE profile names, which was previously referred to as the z/OS security domain, has been updated to SAF profile prefix. Additionally, the corresponding property name in the security.xml file has been updated to com.ibm.security.SAF.profilePrefix The old property names are security.zOS.domainName and security.zOS.domainType. The term has changed to more accurately describe the purpose of this property and to avoid confusion with the WebSphere security domains feature that was introduced in Version 7.0. If a SAF profile prefix is specified and scriptCompatiblity is a false value, further action is not necessary during migration; the old properties are converted to the new properties.

Note: The SAF distributed identity mapping feature is not supported in a mixed-version cell (nodes prior to WebSphere Application Server Version 9.0).

[IBM i] 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 9.0 profile, and all of the Secure Socket Layer-enabled clients and servers that connect to WebSphere Application Server.

[IBM i] IBM i *SYSTEM certificate stores for applications are deprecated in WebSphere Application Server Version 5. In WebSphere Application Server Version 9.0, you must migrate your applications to use Java™ keystores.

If you are migrating a Version 6.0.x environment with Sync to OS Thread enabled to a Version 9.0 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 Version 6.1 and later. 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 trusted 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.