Connection security in Oracle Integration 3: identity, TLS trust and network

An Oracle Integration connection can reach the server and still lack permission for the operation. It can have correct credentials and fail because the target's certificate is not trusted, or because the agent cannot reach the identity service. These are three different causes, and each one is fixed in a different place.

This article separates those conditions (call direction, authentication, TLS trust and agent connectivity) and proposes a per-connection record that allows reviewing and renewing them without depending on a single person. The scope is Oracle Integration 3.

Call direction and owners

The starting point is an inventory with source application, target, operation and direction of each call. In the REST Adapter, a trigger connection receives requests that start an integration and an invoke connection calls an external service; their security configurations are not interchangeable. The role-based connections documentation describes that separation and clarifies that agent configuration does not apply to the trigger role.

An integration that receives a request and then writes to another system contains two trust relationships, approved separately. A valid identity for entering OIC does not, by itself, justify administrative access to the target of the subsequent call.

We recommend assigning each connection an operational owner in addition to the developer who created it. That owner knows which integrations use it and which changes require coordination with the external system's team. Including the environment in the connection name reduces the risk of altering production during a permissions review.

Authentication policies by access type

The policy must be compatible with the adapter and with the consumed service. For a process acting under its own identity, OAuth Client Credentials is appropriate if the provider supports it; a call made on behalf of a person requires the corresponding flow. Oracle describes the REST Adapter OAuth patterns and refers to the provider's documentation for the choice.

The OAuth application registration should be independent of any individual's account, and the authorized scopes documented by the target's owner. Using an administrative account to pass a connection test creates an exception later inherited by every integration that reuses that connection.

If the target only supports basic authentication, a technical account with limited permissions, HTTPS and an explicit password rotation policy are required. There is a documented nuance: in REST, testing an invoke connection with basic authentication does not validate the credentials. The connection creation guide states that validation requires invoking an idempotent API.

Trust and identity in TLS

Two objects should be distinguished. A trust certificate validates the external server; an identity certificate lets the client identify itself when the target requires mutual authentication (mTLS). For the REST Adapter, Oracle separates uploading public certificates for one-way SSL from uploading a JKS keystore with a private key for two-way SSL, according to the certificates guide for external services.

Both objects do not carry the same sensitivity. The private key and keystore passwords require restricted access, and each connection should record the alias it uses. The certificate chain is requested from the target's administrator together with its renewal procedure; a file of unknown origin should not be installed.

It must also be clear on which leg the certificate is validated. The connection between the agent and Oracle Integration is different from the one between the agent and an internal application. To add trust on the agent host, Oracle documents importing into its store and the subsequent restart in Install a Certificate on the Agent Host.

When the REST Adapter reaches an mTLS endpoint through the agent, a specific mutual authentication procedure applies: the identity is configured on the agent host and the connection enables two-way SSL. The alias configuration of a direct connection does not carry over, since Oracle states that field is not supported in this scenario.

Connectivity Agent: exposure and operation

The Connectivity Agent initiates communication with Oracle Integration through outbound requests and polls for pending work; it needs no inbound ports on the local system, according to the official agent description. The host, however, does need egress to OIC services and reach to the authorized internal applications.

Oracle Integration 3 authenticates the agent with OAuth 2.0, unlike the basic authentication Generation 2 supported. Consequently, egress rules must include the identity service as well as the integration service. In a migration, a rule that worked with the previous agent does not guarantee connectivity for the new one.

The agent should be installed with least privilege and restricted access to its directory. The preconfigured InstallerProfile.cfg file contains OAuth parameters, including the client identifier and secret, and must be treated as sensitive material. The installation guide explains its association with the agent group and requires removing the installation key when finished.

Host operation also needs owners: upgrades, process monitoring, access to diagnostics and, where applicable, proxy configuration. The agent's availability depends on an environment administered by the organization, not by the OIC provider, and the support model should reflect that.

Credential governance and renewal

Secrets belong in the adapter's security fields and must not be repeated in mappings, examples or support notes. For custom OAuth flows, the REST Adapter offers parameters bound to obfuscated security fields instead of literal values in requests. Screenshots used for support require the same review.

A renewal is an operational change with known dependencies. The recommended sequence is to identify affected integrations, obtain the new credential through the authorized channel, test it with equivalent permissions in a controlled environment, confirm real execution after the change and retire the old credential according to the provider's conditions.

The certificate inventory records expiry, issuer, alias and renewal owner; the OAuth client inventory adds the registration administrator and the revocation procedure. Neither contains the secret: their purpose is to locate and govern the credential, not to duplicate it.

Verification before activation

The test must cover the full path and distinguish network, trust and authorization failures. It includes one permitted operation and one negative check: the identity must not gain access outside its function. Evidence is kept without passwords, tokens or unnecessary business data.

• Connection role (trigger or invoke) and owner of each endpoint confirmed.
• Adapter policy validated for the chosen access type.
• TLS trust reviewed on the component that executes the call.
• Agent egress to OIC and to the identity service verified.
• Safe operation executed to confirm credentials and permissions.
• Owners and renewal procedure recorded before activation.

Xterra Engine performs connection security reviews for Oracle Integration from this inventory, one connection at a time.