We are in the process of updating the contents of this blog to reflect the latest changes. Until then, please consider the current content deprecated.
With the increasing adoption of Oracle Cloud among customers, one of the key challenges the customers' security teams face is managing network access for the newly purchased SaaS services.
The security teams are firm on enforcing the rules and regulations around IT security that are already in place, and they expect their new SaaS subscriptions to adhere to these rules as well. One such rule is controlled network access, and IP-Address Whitelisting is one approach for achieving it.
IP Whitelisting is the process of creating lists of IP Addresses (or ranges) from which internet traffic is allowed to pass through a firewall. With this setup all 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 access to and from their Fusion SaaS pods.
Fusion Cloud is a set of single-tenant SaaS applications offered by Oracle, and it includes Financials Cloud, Global HR, Sales Cloud, Engagement Cloud, and SCM Cloud and other subscriptions.
Now, IP Whitelisting for Fusion Cloud may be needed at various places in the overall network, depending on the use-case. The picture below summarizes three such use-cases:
Moreover, customers can access their Fusion Cloud instances in three network configurations :
Akamai Acceleration enabled
VPN extended to their on-prem Data Center (DC), although VPN discussion is out of scope for this blog.
The rest of this blog is divided in two main sections, with Akamai enabled, and disabled. Within each section I will provide ways of achieving the three usecases in the picture above.
Though we are not discussing VPN in this blog, it is worth mentioning that for a given Fusion pod the customer can either have Akamai or VPN, but not both. Akamai and VPN are incompatible with each other.
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 :
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.
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.
Now, although Akamai is highly recommended for optimal UI experience, one downside of Akamai 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.
There are two ways to still achieve usecase#1 :
One way to whitelist IP Addresses for Akamai enabled SaaS endpoints is by using the Akamai Client Access Control (CAC) approach.
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.
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:
'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
Whitelist the IP 123.456.7.89
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 essentially we bypass Akamai and lose all its benefits.
Hence this approach should be implemented only on those machines which access Fusion Cloud APIs only, such as Java Cloud Service. And end-users should continue to access Fusion UI from their local browsers to receive all Akamai benefits.
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
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
In some cases, customers may choose to disable Akamai for their Fusion SaaS pod.
This is typically accomplished by logging an SR.
Once Akamai is disabled, the SaaS pod's DNS name translates to the pod's actual IP Address. Typically there are 13 such IP Addresses provided to the customer, 12 for each Fusion domain and 1 for the IDM domain (this will change with Rel-13 though, as number of domains reduce).
The three networking use-cases are then accomplished as follows :
Usecase#1 : Since the customer directly gets the static end IP addresses, it is relatively straightforward to whitelist them.
Usecase#2 : This is NOT possible today if Akamai is disabled. Oracle cannot whitelist IP addresses at the SaaS pod if Akamai is disabled.
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.