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 8.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 8.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.
- When migrating from WebSphere Application Server Version 7.x to Version 8.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 8.0.
When migrating from WebSphere Application Server Version 7.x to Version 8.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 8 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 8.0 on a different machine, the keytab and configuration files for Kerberos must be at the same location on the Version 8.0 machine as on the Version 7.x machine or the configuration will not work.
Procedure
Results
The security configuration of previous WebSphere Application Server releases and its applications are migrated to the new installation of WebSphere Application Server Versão 9.0.
What to do next
You must migrate any custom class files that are not migrated.
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.
![[z/OS]](../images/ngzos.gif)
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 Versão 9.0 profile, and all
of the Secure Socket Layer-enabled clients and servers that connect
to WebSphere Application Server.
IBM i *SYSTEM
certificate stores for applications are deprecated in WebSphere Application Server Version 5. In WebSphere Application Server Versão 9.0, you must migrate
your applications to use Java™ keystores.
![[z/OS]](../images/ngzos.gif)
- 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.
- 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.