Best Practices from Oracle Development's A‑Team

Fusion Cloud IP-Whitelisting


With the increasing adoption of Oracle Cloud among customers, one of the key challenges the IT security teams face is managing network access of the newly purchased SaaS services.

The security teams are strict on enforcing the rules and regulations around IT security, and they expect their new SaaS subscriptions to adhere to these rules as well. One such rule is controlling network access, and IP-Address Whitelisting is the predominant solution to achieve that.

IP Whitelisting is the process of creating lists(or ranges) of IP Addresses, such that all other IPs are denied access except for those included in the whitelist.

In this blog I will discuss various options available to Oracle Fusion Cloud customers for whitelisting their Fusion pods.

Fusion Cloud is a suite of SaaS applications offered by Oracle, and it includes Financials Cloud, Global HR, Sales Cloud, Engagement Cloud, and SCM Cloud and other subscriptions.

Whitelisting Usecases

In general, IP Whitelisting for Fusion Cloud may be implemented at various layers in the overall network architecture depending on the requirements. The image below summarizes three of the most commonly needed layers:


  1. Firewall at Customer DC disables all outbound access unless whitelisted. In such case the Fusion pod IPs would have to be whiltelisted at the firewall

  2. Customer wants the SaaS pod to be accessible only from certain IP ranges, such as the customer's DC. In this case the Fusion pod will have to whitelist a customer-supplied list of IP addresses, such that it only accepts requests originating from those IPs.

  3. Customer has configured outbound invocation from their Fusion pod to an API hosted in customer's DC, and they would like to whitelist their firewall to accept incoming requests from the Fusion pod only.

Moreover, customers can access their Fusion Cloud instances in two network configurations :

  1. Akamai Acceleration enabled: This is the default posture for any Fusion pod.

  2. Akamai disabled: When customers have requirements such as VPN or Fast Connect, Akamai is disabled as part of the setup. Akamai cannot be disabled without an associated VPN or FastConnect setup.

The rest of this blog is divided in two main sections, Akamai enabled, and Akamai disabled. In each section I will provide ways of achieving the three usecases in the picture above.

1. Akamai Enabled

By default all Fusion Cloud instances are provisioned with Akamai acceleration enabled over the internet.

Using the Akamai Content Delivery Network provides the following benefits :

  1. Connection Acceleration: Akamai constantly accesses the internet health and figure the best route from the client's browser to the SaaS pod. This is especially beneficial when users from various geographical locations access the Fusion instance.

  2. Static Object Offloading : Static UI objects such as css, images, js files etc. are offloaded and cached in the physically nearest Akamai edge server. This prevents network trips to Oracle Data Center for static objects, hence leading to faster page load times.


It must be noted that static caching benefits apply for UI caching only.
A SOAP or REST API call doesn't benefit from static caching as the request has to hit the actual (or origin, in Akamai parlance) Fusion servers. Although these calls still benefit from connection acceleration.

1.1 Achieving Usecase#1

Although Akamai is highly recommended for optimal UI experience, one downside is that the chosen edge server for any request is dynamic, which means the SaaS endpoint's DNS resolution for each request could result in different IP Addresses.
In short, using Akamai we cannot guarantee a static IP Address for Fusion SaaS hostnames, which makes IP whitelisting difficult.

Screen Shot 12-08-17 at 02.37 PM

There are two ways to still achieve usecase#1 :

1.1.1 Akamai CAC

One way to whitelist IP Addresses for Akamai enabled SaaS endpoints is by using the Akamai Client Access Control (CAC).

In this approach, customers log an SR with Oracle Support to move their pod to the CAC network. Once moved, Oracle provides ~1700 IP Addresses which customers should allow and whitelist in their network, with the guarantee that the SaaS endpoint's DNS would always translate to one of the ~1700 IP Addresses.

This way customers can continue to use Akamai, and manage access to their pods as well.

1.1.2 Using hosts file spoofing

We know that for an Akamai enabled Fusion endpoint, such as abc.fs.us2.oraclecloud.com, the translated IP Address is dynamic. But for every such endpoint, a corresponding abc.origin-fs.us2.oraclecloud.com endpoint exists, which translates to the IP Address of the origin servers, i.e. the actual servers within Oracle data center.

This means that we could use the 'origin-' hostnames to lookup and whitelist the origin servers directly. However, to enforce use of the Akamai network, Oracle Cloud rejects all the requests coming to the origin- endpoints from outside the Akamai network.

Hence, the following steps can be used as a workaround:

  1. 'nslookup' the IP of https://abc.origin-fs.us2.oraclecloud.com (say it is 123.456.7.89 ), and create an entry in /etc/hosts for abc.fs.us2.oraclecloud.com and translate it to 123.456.7.89

  2. Whitelist the IP 123.456.7.89

  3. Repeat the above steps for all the required Fusion servers, such as abc.fs.us2.oraclecloud.com , abc.login.us2.oraclecloud.com etc.

Essentially we spoof the HTTP headers so that although we hit the origin- IP Address, we ensure the hostname in the HTTP packet is still abc.fs.us2.oraclecloud.com , thus ensuring the packets are not rejected.

By following this approach we only need to whitelist the origin- IP Addresses. But we bypass Akamai and lose all its benefits.

Hence this approach should be implemented only on those machines which access Fusion Cloud APIs for programmatic access, such as OCI Compute, FN, etc. And end-users should access Fusion UI from their local browsers to receive all Akamai benefits.

Achieving Usecase#2

With Akamai enabled, usecase#2, i.e. whitelisting IP Addresses within the Fusion pod, can be achieved by filing an SR against Oracle Support, providing the list of IPs to be whitelisted as part of that.

The list of IP addresses can be revised as well, although with each revision the complete list should be provided, not just the delta.

The detailed process is documented in the Support Note 2089639.1

Achieving Usecase#3

Usecase#3 basically requires finding out the list of IP Addresses that could be the source IPs of requests originating from Fusion pods, which the customer should whitelist in their firewall.

This information is available at a data center level, in the Support Note 1903739.1

2. Akamai Disabled

As mentioned above, for custom Networking configurations such as VPN or Fast Connect, Akamai is disabled.

Once Akamai is disabled, the SaaS pod's DNS name translates to the pod's actual IP Address.

The three networking use-cases are then accomplished as follows :

  1. Usecase#1 : Since the customer directly gets the static end IP addresses, it is relatively straightforward to whitelist them.

  2. Usecase#2 : As part of the associated VPN or FastConnect setup, customer can provide a list of IP Addresses to be whitelisted, and Oracle can whitelist those.


In this blog we discussed a few whitelisting options that are available for Fusion SaaS customers on Akamai.
We also discussed how they can choose not to use Akamai for their SaaS instance, and the associated whitelisting ramifications.


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content