Oracle Integration Cloud enables easy integration between diverse applications, including exposing application interfaces as REST endpoints. It can also host Visual Builder Cloud instance, which lets you develop web applications quickly. Since web applications are susceptible to malicious attacks from bad actors, they should be protected using a WAF (web application firewall).

When an OIC instance is created, OIC generates an endpoint (URL) to access various resources such as Service Console and REST endpoints. The format of the URL is:

https://<instance-display-name>-<tenancy-name>-<region-code>.integration.ocp.oraclecloud.com

e.g., myoic-acmecorp-yu.integration.ocp.oraclecloud.com .

This is publicly accessible, i.e., the URL can be accessed from the internet. However, you can restrict access to this URL from the internet, and we will look into that below.

Many customers require that they access the OIC instance using a custom domain name instead, e.g. myoic.acmecorp.com. To protect access to the OIC resources using the custom domain URL with WAF, the following architecture can be used.

                                                                           Fig 1

The Architecture

The architectural components are as follows:

• Load Balancer + WAF: The OIC custom domain - myoic.acmecorp.com in Fig 1 above - gets resolved to the load balancer(LB)'s IP address (using the DNS). Various rules defined in the WAF can scrutinize the incoming traffic and block malicious traffic. The load balancer is placed in a public subnet to make it accessible from the internet.
• API Gateway: The load balancer requires a backend's IP address to route incoming traffic. OIC gen2, however, does not publish it's inbound IP address. The solution would be to to foward the request to an API Gateway, which supports domain name of the backend (in this case the OIC instance itself - myoic-acmecorp-yu.integration.ocp.oraclecloud.com), acting as an intermediary. That is, the API GW's IP address is used in the LB's backend. The API Gateway is placed in a private subnet, to make it accessible only from within the load balancer's VCN.
• Service Gateway: the liaison between the VCN and the Oracle Service Network (OSN).
• The routing table associated with the API Gateway's (private) subnet has a routing rule to forward all OSN based traffic (which includes OIC) to the Service Gateway. The target 'OIC' shown in Fig 2 below, is the name of the service gateway in my implementation.

                                                                                Fig 2

• OIC Network Access: The NAC in OIC is set to accept traffic only from the VCN. This way, you can force all traffic being routed via the LB + WAF using only the custom domain myoic.acmecorp.com, while blocking access to the original OIC instance URL myoic-acmecorp-yu.integration.ocp.oraclecloud.com from the internet.

                                                                      Fig 3

Architecture in action: accessing Service Console

The service console URL using the custom domain name is https://myoic.acmecorp.com/ic/home. This request will first land on the load balancer due to DNS configuration. The trajectory of the request is as shown in Fig 1 above. If everything goes well, the service console gets displayed as below. I have also turned on the 'Developer Tools' of Chrome to show the actual requests/responses which are flying down the wire.

                                                                                    Fig 4

Let us focus on the first few calls above. I am including the HAR snippet to highlight the actual calls.

                                                                         Fig 5

1. After the user initiates the request for service console, /ic/home 
2. OIC starts an OIDC flow and redirects the user to OCI IAM Domain for authentication, /authorize
3. After successful authentication, IAM Domain will redirect to OIC, /cloudgate/v1/oauth2/callback
4. OIC after validating the response from IAM Domain, redirects the user to /ic/home.
5. Subsequently, OIC fetches multiple pages from the /ic/*.

The key point here is that, essentially two endpoints of OIC are invoked - /ic and /cloudgate. Hence in the API GW configuration, two deployments are needed accordingly.

                                                                          Fig 6

For the /ic deployment, I have defined the following four routes -

1. Route 1: /home

                                                                       Fig 7

2. Route 2: /home/{uri*}

                                                                   Fig 8

3. Route 3: /ic/integration/{uri*}

                                                                      Fig 9

4. Route 4: /api/{uri*}

                                                                Fig 10

For the /cloudgate deployment, only one route is required.

                                                                     Fig 11

Note that the backend is the original OIC instance URL. Since API GW acts as a proxy and initiates the connection to the OIC, it inserts the (HTTP) Host header of itself. This will not work since the host header sent to OIC needs to be myoic.acmecorp.com. To achieve this, we need to insert the HOST header explicitly for all the routes - 

                                                Fig 12

REST Endpoints

Accessing REST endpoints exposed by OIC have a trajectory similar to service console. However, unlike the service console use case where an end user accesses, REST endpoints can also be invoked by a client application. Refer to my blog post which goes into more detail about this aspect. In that blog post I have accessed the 'Echo' REST endpoint. Invoking that endpoint but with the custom domain name forces the request to go via the load balancer (Fig 1) - 

The output is as follows, thus validating the architecture - 

                                                                          Fig 13

OIC VBCS Applications

Although I have not tested accessing VBCS applications, I believe this architecture will be applicable for those use cases too. When VBCS applications are created with their custom domain names, an alias is generated. This alias can be used as the backend URL in the API GW's routing rule, similar to the service console use case.

Advanced Architecture

You can design more advanced architectures by extending the above solution. For example, there could be a requirement to make the service console accessible only from on-prem data center while having external users access VBCS apps from the internet. The network control setting in OIC can be configured to allow traffic not only from the VCN but also the on-prem data center. This of course assumes that the VCN is designed properly with nonoverlapping CIDR ranges between the data center and the VCN.

                                                                         Fig 14 

In the above figure, the customer data center is connected to the (OCI) VCN using Fast Connect private peering. With transit routing in place, OIC admins can access the service console using the native URL: the traffic remains confined to the customer's network. Any access from the internet is blocked.

Summary

This blog post discusses a solution to secure OIC Service Console, REST endpoints and VBCS applications with OCI WAF, API Gateway and Service Gateway.