Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer

Use case one covers all patterns of a scenario in which a trusted organization’s API is exposed to a trusted organization’s API consumer.

Pattern 1: Organization Internal API Exposed to an Organization Internal Consumer

Pattern examples:

A sales application accesses a customer service API in which both sales and customer service are internal areas of the customer organization
A call center application calls the API exposed by the customer domain to retrieve customer information
A mobile bank calls customer and account services to display the account overview screen to the end consumer

Pattern 1A: Organization Internal API Exposed to an Organization Internal Consumer that Uses the Same VPC or Network

In this use case pattern, both services are available on the same infrastructure, such as the same public cloud VPC, datacenter, or Kubernetes cluster. You can deploy Omni Gateway as either a sidecar or a standalone gateway.

For both standalone and sidecar mode, Omni Gateway and the APIs are in the same internal network.

The following diagram shows the physical implementation of a standalone Omni Gateway running in Connected Mode. A network policy (Netpol) permits ingress access only from Omni Gateway. You can configure the consumer application in the same or different namespace from Omni Gateway and the provider services.

A more detailed view of UC1 contains load balancers and Netpol protection

When the API provider is located in a different Kubernetes cluster from Omni Gateway and the consumer application, you can do either of the following:

Deploy an Omni Gateway runtime on each of the clusters, as in Pattern 1B.
Establish network restrictions in the secure channel between clusters and deploy Omni Gateway in only one of them, as shown in the following diagram. The second cluster only allows connections from an Omni Gateway that acts as an ingress controller.

A detailed view of pattern 1A, which contains the necessary services to support Omni Gateway

Pattern 1B: Organization Internal API Exposed to an Organization Internal Consumer that Uses a Different VPC or Network

In this pattern, the API provider is isolated from the API consumer. However, there is a secure communication channel available between the two networks.

You deploy Omni Gateway as an ingress behind a firewall because traffic is considered external to the location of the provider. Omni Gateway receives and processes the incoming traffic.

You can use Omni Gateway to terminate the TLS or mTLS connection if required.

Information travels from a trusted network to the internal network that contains Omni Gateway.

The following diagram shows the physical implementation on Kubernetes.

The previous networks are now Kubernetes clusters and there are load balancers that separate the APIs from Omni Gateway.

Pattern 2: Organization Internal API exposed an Organization External Consumer

In pattern two, the organization-owned API is isolated from the organization-owned API consumer, for example, in a package delivery tracking API that is accessed from a user interface. The consumer can access the exposed API only via the internet. In this use case, you deploy Omni Gateway as an ingress.

Consumer application requests pass through the internet and a firewall before reaching Omni Gateway.

This pattern is similar to Pattern 1B. However, in this pattern, traffic arrives from the public internet instead of from a private channel. Because traffic is coming from the public internet, you must add additional controls to strengthen communication security before reaching Omni Gateway.

The following diagram shows the physical implementation of a scenario in which an organization’s internal API is exposed to an organization’s internal consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming external mTLS connection.

The previous networks are now Kubernetes clusters, there are load balancers separating the APIs from Omni Gateway, and mTLS connections to external networks.

Pattern 3: Organization External API Exposed to an Organization Internal Consumer

In pattern three, the API Consumer is in the same network as Omni Gateway. You can use Omni Gateway to monitor, control, and enrich the flows to external services. For example, Omni Gateway can provide rate limiting for the external access traffic, or metrics and analytics tracking for this external service connection.

Pattern examples:

A payments service must obtain exchange rates from an external service provider.
An internal API Consumer accesses the organization’s external ServiceNow instance (SaaS service).

For pattern three, you deploy Omni Gateway as a standalone gateway that acts as an egress container.

Omni Gateway is deployed as an egress to monitor incoming traffic from the external API.

The following diagram shows the physical implementation of a scenario in which an organization’s external API is exposed to an organization’s internal consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming external mTLS connection.

The previous networks are now kubernetes clusters. There are load balancers that separate the APIs from Omni Gateway and mTLS connections to external networks.

Pattern 4: Organization External API Exposed to an Organization External Consumer

In pattern four, Omni Gateway acts as an intermediary between two organizations' external entities, for example, when an organization’s WorkDay instance (SaaS service) accesses the organization’s ServiceNow instance (SaaS service). In this pattern, Omni Gateway runs as an ingress and egress that applies secured communication and policy enforcement.

Omni Gateway acts as an intermediary between an external application and external API.

The following diagram shows the physical implementation of a scenario in which an external organization’s API is exposed to an external organization’s consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming organization’s external mTLS connection.

A detailed view of pattern four, which contains the necessary services to support Omni Gateway