Migrate, coexist, and interoperate - Security considerations
Use this topic to migrate the security configuration of previous WebSphere Application Server releases and its applications to the new installation of WAS.
This information addresses the need to migrate the security configurations from a previous release of IBM WebSphere Application Server to WebSphere Application Server 8.0. Complete the following steps to migrate the 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.
- We can optionally disable security in the previous release before migrating the installation. No logon is required during the installation.
- (zos) 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.
In WebSphere Application Server Version 8.0, be aware of the following additional migration requirements for security:
- When migrating from WebSphere Application Server Version 7.x to Version 8.0, if we have a business need to preserve security audit logs from the older release first archive the security audit log files in Version 7.x. WAS does not support the migration of security audit log files from the older release to Version 8.0.
- (zos) 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 the WAS 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.
- (zos) Migrate the appropriate product configuration. We can migrate the base application server node, a deployment manager, and a federated node.
- (dist) Use the First steps console to access the WebSphere Customization Toolbox, and run the Migration Management Tool.
- 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
- On the First steps console panel, click WebSphere Customization Toolbox.
- Open the Migration Management Tool.
- Follow the instructions provided to complete the migration.
- (iseries) 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 WAS v8.5.
What to do next
We must migrate any custom class files that are not migrated.
(zos) If we 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 security.xml 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.
(zos)
The SAF distributed identity mapping feature is not supported in a mixed-version cell (nodes prior to WebSphere Application Server v8.5).
(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 WAS v8.5 profile, and all of the Secure Socket Layer-enabled clients and servers that connect to WebSphere Application Server.
(iseries) IBM i *SYSTEM certificate stores for applications are deprecated in WebSphere Application Server Version 5. In WebSphere Application Server v8.5, migrate the applications to use Java keystores.
(zos) If we are migrating a Version 6.0.x environment with Sync to OS Thread enabled to a v8.5 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 WAS, 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 (zos) 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 (zos) System Authorization Facility classes and profiles.
Subtopics
- Interoperating with previous product versions
IBM WebSphere Application Server inter-operates with the previous product versions. Use this topic to configure this behavior.
- (dist)(zos) Interoperating with a C++ common object request broker architecture client
WebSphere Application Server supports security in the CORBA C++ client to access-protected enterprise beans. If configured, C++ CORBA clients can access protected enterprise bean methods using a client certificate to achieve mutual authentication on WebSphere Application Server applications.
- Migrate trust association interceptors
Use this topic to manually migrate trust associations.
- Migrate Common Object Request Broker Architecture programmatic login to Java Authentication and Authorization Service (CORBA and JAAS)
Use this topic as an example of how to perform programmatic login using the CORBA-based programmatic login APIs.
- Migrate from the CustomLoginServlet class to servlet filters
Use this topic to allow migration in an application that uses form-based login and servlet filters without the use of the CustomLoginServlet class.
- Migrate Java 2 security policy
Use this topic for guidance pertaining to migrating Java 2 security policy.
- Migrate with Tivoli Access Manager for authentication enabled on a single node
When Tivoli Access Manager security is configured for the existing environment and security is enabled for a single node, we can migrate to WebSphere Application Server, v8.5.
- Migrate with Tivoli Access Manager for authentication enabled on multiple nodes
When Tivoli Access Manager security is configured for the existing environment and security is enabled for multiple nodes, we can migrate to WebSphere Application Server, v8.5.
- (iseries) Migrate Java thin clients that use the password encoding algorithm
To migrate Java thin clients that are enabled for OS400 password encoding, use the following information to modify the Java client invocation so that the os400.security.password properties are no longer set on the invocation.
- (dist)(zos) Migrate unrestricted jurisdiction policy files, local_policy.jar and US_export_policy.jar
We can migrate the unrestricted jurisdiction policy files, local_policy.jar and US_export_policy.jar.
Related concepts
Java Authentication and Authorization Service Web component security Java EE connector security (zos) System Authorization Facility classes and profiles
Related tasks
Configure inbound identity mapping