Integration Use Cases
The following integration use cases are determined by the ownership of the API provider and API consumer. Each use case shows physical patterns that demonstrate the necessary services in the system.
For the following use case diagrams, Flex Gateway is running in Connected Mode. However, you can also run Flex Gateway in Local Mode or use a combination of Connected Mode and Local Mode for separate runtimes in the same or in different environments.
The use case diagrams use Kubernetes terminology, but you can extend the architecture to other technology stacks that have the appropriate network controls applied.
Flex Gateway supports four use cases:
-
Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer
-
Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer
-
Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer
-
Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer
Each use case supports different integration patterns that vary depending on the location of APIs relative to the network in which Flex Gateway is located. You can use different use case patterns, depending on the different API owners and networks in your system.
In each use case, there are three different classifications of networks. The classifications describe the relation of each network to your organization and the network that Flex Gateway is in:
-
Organization internal
Networks owned by your organization and in the same network as Flex Gateway
-
Organization external
Trusted networks external to your organization but in a different network than Flex Gateway, for example, your organization’s Splunk instance
-
Non-Organization external
External networks untrusted by your company and in a different network as Flex Gateway. An API provider’s or API consumers network status affects the necessary security protocols (mTLS) you take when communicating between networks
If an API provider or API consumer is organization-owned, it belongs to either the organization’s internal network or its external networks.
The following tables:
-
Relate the previously mentioned use cases to use case patterns
-
Show the networks involved in the pattern
-
Indicate whether Flex Gateway acts as an ingress, egress, or both
Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer
| Pattern | Provider Network | Consumer Network | Role of Flex Gateway |
|---|---|---|---|
Organization internal |
Organization internal |
Ingress |
|
Organization internal |
Organization internal |
Ingress |
|
Organization internal |
Organization external |
Ingress |
|
Organization external |
Organization internal |
Egress |
|
Organization external |
Organization external |
Ingress and egress |
Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer
| Pattern | Provider Network | Consumer Network | Role of Flex Gateway |
|---|---|---|---|
Organization internal |
Non-organization external |
Ingress |
|
Organization external |
Non-organization external |
Ingress and egress |
Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer
| Pattern | Provider Network | Consumer Network | Role of Flex Gateway |
|---|---|---|---|
Non-organization external |
Organization internal |
Egress |
|
Non-organization external |
Organization external |
Ingress and egress |
Use Case 4: Non-Organization-Owned API Exposed to an External Non-Organization-Owned API Consumer
| Pattern | Provider Network | Consumer Network | Role of Flex Gateway |
|---|---|---|---|
Non-organization external |
Non-organization external |
Ingress and egress |
mTLS considerations for integration flows
Flex Gateway supports Mutual Transport Layer Security (mTLS) for all Flex Gateway-initiated and Flex Gateway-terminated connections. Mulesoft recommends using mTLS on all communication flows.
For inbound connections that cross a network security boundary, use a network application firewall as close to the boundary as possible. For inbound connections, configure the external mTLS connection to terminate at the firewall and configure a new mTLS context between the firewall and Flex Gateway.
Certificate authorities
Different certificate authorities (CA) participate in the mTLS connection, depending on the type of integration. In the use case diagrams, color codes and labels represent the different mTLS contexts. Each mTLS context contains a truststore that contains CAs for validating far-side certificates and a keystore that contains a certificate issued by this same CA. The following table describes the three possible mTLS contexts:
| mTLS context symbol | Certificate authority | Description |
|---|---|---|
|
Organization internal mTLS |
For internal network communication, the expectation is that only the customer organization uses these certificates within the internal network. |
|
Organization external mTLS |
For external communication with trusted parties over the public internet, the organization can issue certificates that external consumers or third parties can use to access the services provided by the organization. |
|
Non-organization external mTLS |
For external communication with entities that aren’t trusted, the third party organization controls the CA. The third party CA issues certificates for the organization to use when communicating with third-party services. |
