Oracle Access Manager (OAM) WebGate Guide -Part5 – WebGate Communication

Introduction

The OAM Server communication mode is defined during the Agent registration. There may come a time when it may become necessary to change the way the OAM Server communicates with the WebGate after a successful agent registration. The below information will provide a high-level understanding of the basics behind the communication used and to provide a starting point for implementation.

Oracle Access Protocol (OAP) Over Rest

This communication mode is only available with the 12.2.1.4.x OAM Server 12.2.1.4.x and Higher; and the OAM 12.2.1.4.x and Higher WebGates. It is the default when registering a WebGate/Agent.

Communication Protocols

Oracle Access Protocol (OAP) Channel

This communication modes leverages the “Transport” (TCP) network layer to route and load balance requests. The below communication modes are applicable for the OAM Server 12.2.x and the certified OAM 11.1.2.3.x and Higher WebGates.

Communication Modes

Transport Layer Security (TLS)

The Transport Layer Security, or TLS, is a widely adopted security protocol designed to facilitate privacy and data security for communications over the Internet. A primary use case of TLS is encrypting the communication between web applications and servers, such as web browsers loading a website. TLS can also be used to encrypt other communications such as email, messaging, and voice over IP (VoIP). In this article we will focus on the role of TLS in web application security.

What?

There are three main components to what the TLS protocol accomplishes: Encryption, Authentication, and Integrity.

• Encryption: hides the data being transferred from third parties.
• Authentication: ensures that the parties exchanging information are who they claim to be.
• Integrity: verifies that the data has not been forged or tampered with.

How?

For a website or application to use TLS, it must have a TLS certificate installed on its origin server (the certificate is also known as an “SSL certificate” because of the naming confusion described above). A TLS certificate is issued by a certificate authority to the person or business that owns a domain. The certificate contains important information about who owns the domain, along with the server’s public key, both of which are important for validating the server’s identity.

A TLS connection is initiated using a sequence known as the TLS handshake. When a user navigates to a website that uses TLS, the TLS handshake begins between the user’s device (also known as the client device) and the web server.

During the TLS handshake, the user’s device and the web server:

• Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
• Decide on which cipher suites (see below) they will use
• Authenticate the identity of the server using the server’s TLS certificate
• Generate session keys for encrypting messages between them after the handshake is complete

The TLS handshake establishes a cipher suite for each communication session. The cipher suite is a set of algorithms that specifies details such as which shared encryption keys, or session keys, will be used for that particular session. TLS is able to set the matching session keys over an unencrypted channel thanks to a technology known as public key cryptography.

The handshake also handles authentication, which usually consists of the server proving its identity to the client. This is done using public keys. Public keys are encryption keys that use one-way encryption, meaning that anyone with the public key can unscramble the data encrypted with the server’s private key to ensure its authenticity, but only the original sender can encrypt data with the private key. The server’s public key is part of its TLS certificate.

Once data is encrypted and authenticated, it is then signed with a message authentication code (MAC). The recipient can then verify the MAC to ensure the integrity of the data. This is kind of like the tamper-proof foil found on a bottle of aspirin; the consumer knows no one has tampered with their medicine because the foil is intact when they purchase it.

• OAM managed server is tied to the JDK it uses, which defines the TLS version.
• Back Channel – Any traffic that goes directly between the OAM Server and the WebGate
• Front Channel – Any communication between the OAM server and WebGate that happens though the user’s browsers. (TLS 1.2/1.3)

Wrap up

• Oracle Access Protocol (OAP) Over Rest communication mode it the prefeered mode and is only available with the 12.2.1.4.x OAM Server 12.2.1.4.x and Higher; and the OAM 12.2.1.4.x and Higher WebGates. It is the default when registering a WebGate/Agent.
• Oracle Access Protocol (OAP) Channel communication mode (OPEN, SIMPLE, CERT) leverages the “Transport” (TCP) network layer to route and load balance requests. The below communication modes are applicable for the OAM Server 12.2.x and the certified OAM 11.1.2.3.x and Higher WebGates.
• The Transport Layer Security (TLS), the OAM managed server is tied to the JDK it uses; which defines the TLS version. The Back Channel, any traffic that goes directly between the OAM Server and the Webgate. The Front Channel, any communication between the OAM server and WebGate that happens though the users browsers. (TLS 1.2/1.3).

Related Articles:

• Oracle Access Manager (OAM) WebGate Guide – Part Four – WebGate Highly Available (HA) Architecture – This is the fifth part in a 6 part series of blogs that discuss the Oracle Access Manager (OAM) WebGate component with respect to how it communicates with the OAM server.