1. Upgrading Oracle Access Manager
  2. Upgrade Scenarios for OAM

B Upgrade Scenarios for OAM

An upgraded OAM environment can result in the following cases:

  • If WebGate is upgraded and the OAM Server is not, then SSL communication between them uses TLSv1 with MD5 certificates.

  • If OAM Server is upgraded and WebGate is not, then SSL communication between them fails, as the OAM Server rejects MD5 certificates and doesn't support TLSv1. In this case, you need to modify the Java security policy to enable TLSv1, TLSv1.1 and MD5.

  • If both OAM Server and WebGate are upgraded, edit the WebGate profile and copy the WebGate artifacts to the WebGate config folder. SSL communication between the OAM Server and WebGates will use TLSv1.2 with SHA-2 certificates.

WebGates

12c (12.2.1.4.0) WebGates that employ version 4 of the OAP protocol will continue to work with OAM 12c (12.2.1.4.0). However, these WebGates must be upgraded to leverage the full capability of 12c (12.2.1.4.0). To upgrade the WebGates:

  1. Stop the WebGates (OHS/OTD)

  2. Upgrade WebGate binaries to 12c (12.2.1.4.0)

  3. Edit WebGate profile and register the updated profile

  4. Copy the WebGate artifacts to the WebGate config folder

  5. Start the WebGates (OHS/OTD)

Multi-Data Center

If an upgrade results in a 12c (12.2.1.4.0) Primary server and an 12c (12.2.1.3.0) Clone server (or vice versa), then SSL communication between the servers fails. To enable communication between these servers, modify the java.security policy to enable TLSv1, TLSv1.1, and MD5 as suggested above.

Client Certificates

OAM Server 12c (12.2.1.4.0) rejects older client/user X.509 certificates that don't adhere to JDK 8 security requirements. See Release Notes for JDK 8 and JDK 8 Update Releases for MD5- and TLS-related restrictions for the JDK 8 update specific to the system. This behavior is governed by the JDK 8 java.security policy. To ensure acceptance of older client/user X.509 certificates, modify the java.security policy to enable TLSv1, TLSv1.1, and MD5 as described above.

Federation

For scenarios that involve Service Provider (SP) or Identity Provider (IDP) registration, the certificates used may undergo the same limitations as that for Client Certificates listed above.

Note that federation agreements will break if the Token Signing Certificate is changed. As a result, the 12c (12.2.1.3.0) security posture is carried forward after upgrading, which may require enabling the legacy algorithms (TLSv1, TLSv1.1, and MD5), as described above. The use of SHA-2 certificates is supported.

OIC

Similar to Federation, changing the OAuth Token Signing Certificate breaks existing trust relationships. As a result, the 12c (12.2.1.3.0) security posture is carried forward after upgrading, which may require enabling the legacy algorithms (TLSv1, TLSv1.1, and MD5), as described above. The use of SHA-2 certificates is supported.