Contact Us 1-800-596-4880
  1. Homepage
  2. Omni Gateway (1.13)
  3. Omni Gateway Reference Architecture
  4. Integration Use Cases

  5. Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer

Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer

Use case two covers all patterns of a scenario in which an organization-owned API is exposed to a non-organization-owned API consumer; for example, when a user makes a request to your public-facing API.

Pattern 5: Organization Internal API exposed to a Non-Organization External Consumer

In pattern five, the infrastructure of the organization-owned API is isolated from the API consumer. 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.

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

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

Pattern 6: Organization External API exposed to a Non-Organization External Consumer

In pattern six, Omni Gateway acts as an intermediary between two external network entities. Omni Gateway runs as an ingress and egress that applies secure 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 organization external API is exposed to an non-organization external consumer on Kubernetes. The diagram assumes that the firewall terminates the external mTLS connections.

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

See Also