As Oracle Cloud Infrastructure (OCI) is adopted rapidly, customers increasingly ask for guidance on security architecture across Oracle's portfolio of cloud services. In this post, I am sharing best practices from my vantage point of seeing numerous customers succeed with Oracle's SaaS and OCI implementations. 

Security is critical when information crosses boundaries between cloud applications, as is the case with integrations and extensions to SaaS applications. A variety of techniques across cloud services must be applied diligently to help guarantee end-to-end security. The focus of this post is on integrations and extensions for Oracle Fusion SaaS applications (aka. Fusion Applications) on Oracle Cloud Infrastructure (OCI), more specifically, HCM and ERP. The best practices shared in this post may extend to other Oracle SaaS applications.

Here is a high-level view of the cloud services and key security features of each service. 

Security for Integrations and Extensions

OCI and Fusion have their own set of security features, most of which are self-contained in terms of configuration. For example, OCI has features to secure interactions between various services in OCI, while Fusion SaaS services provide features such as Role-based access control. However, certain security features span infrastructure and applications and must be understood and implemented as an integrated solution. Here are some essential security features for integrations and extensions: 

• Federation, commonly SAML-based identity federation
• API security, to secure integration endpoints

Federation

Identity federation enables the trust of user credentials across applications and establishes a single point of security control. The most familiar aspect of federation is that it helps eliminate repetitive logins for applications across departmental or organizational boundaries. Federation is enabled by underlying configurations to establish trust between applications, and, to synchronize users and group memberships between identity and service providers. 

SAML 2.0-based identity federation is the prevailing standard for enterprises. All Oracle services discussed in this post support SAML federation, using built-in capabilities or through Oracle’s Identity Cloud Service (IDCS). Both IDCS and Oracle SaaS Applications can be either Identity providers (IDP) or Service providers (SP) in a SAML 2.0 federation. OpenID Connect (OIDC) is another important, but emerging identity protocol for mobile and web applications. While IDCS supports OIDC, it is not needed for the security architecture presented in this post. There are three common alternatives in federating Fusion SaaS with IDCS. Either Fusion SaaS or IDCS can be an IDP for the federation. It is also typical to have Fusion SaaS and IDCS be SPs to a third-party IDP such as Active Directory Federation Service (ADFS), as shown below.

Federation topologies

Applications can support multiple identity providers and can optionally permit users to pick a login option. Both Fusion SaaS and IDCS support a “chooser” page where customers can pick an IDP or log directly into the application.

A recommended pattern is to associate each Fusion SaaS instance with its own IDCS instance, either as an SP or as an IDP. This allows segregation of Fusion application users of an environment from users of another environment and from administrative users. The IDCS instance created when the tenancy is provisioned (also known as "primordial" IDCS) should only host users and groups for the administration of the OCI tenancy and the OCI infrastructure services. See below the recommended federation topology for multiple Fusion SaaS instances.

Federation with IDCS for multiple Fusion SaaS instances. 

API Security

APIs are the primary way to exchange data between applications on the cloud. It is important to ensure that APIs are secured with maximum security posture, especially when the APIs are exposed over public IP addresses over the internet. Here are some aspects of API security to check off.

• Enforce HTTPS encryption with TLS 1.2 or higher protocol.
• Avoid authenticating with username and password (also known as basic authentication), unless there are no alternatives.
• Adopt standardized mechanisms such as OAuth for authentication. For REST APIs, use JSON Web Tokens (JWT) for authentication. For SOAP web services, use SAML bearer tokens for authentication.
• Enforce authorization based on the principal presented in the token for authentication.

The application services deployed on OCI with REST endpoints must enforce authentication and authorization. Fusion SaaS application API endpoints must also be configured for appropriate authentication and authorization.

JSON Web Tokens are an open, industry-standard RFC 7519 method for representing claims securely between two parties. They are fundamentally similar to SAML 2.0 tokens, but JWT tokens are more common in the cloud. JWT Token Trust is through immutable encrypted message digest generated by the issuer and verified by the service.

Fusion Applications and an OCI API gateway both can validate JWT tokens issued by IDCS. Below is the common token flow for Oracle cloud integrations.

JWT token flow. 

The token flow shown is a simplified flow, in which an application uses client credentials to authenticate with IDCS to obtain a JWT token (also known as a 'bearer token') and then sends the token to the resource service for authentication and authorization. This flow suffices for API security for most application integrations.

In a 2-legged OAuth flow, an access token (commonly a JWT token) and a refresh token to periodically replace the access token are used. Lastly, here is an example of a JWT token with a header and claims. 

Sample JWT token.

Security on OCI

Security on OCI must be considered from multiple perspectives, such as network security, administrative security, and application security. Here are some important security features of OCI by domain:

Administrative Security

• Identity and Access Management (IAM), to maintain users and groups 
• Compartments, to organize services and resources based on access needs
• Policies, to provide a flexible way to define administrative security using IAM groups, compartments, and types of services
• Security zones and Cloudguard allow the definition and enforcement of advanced security policies to govern security across OCI

Network Security 

• Network Security Groups and Security lists provide ways to define fine-grained network security 
• Network resources, to restrict access by IP origin
• Gateways such as Internet gateway, service gateway, and NAT gateway to provide varying levels of access to services
• Private endpoints to provide private, bidirectional access between services in private subnets and supporting managed services on OCI

Application Security

• Identity cloud service (IDCS), an IDaaS service with cloud-security capabilities, such as SAML federation and OAuth
• API gateway, to secure APIs deployed on OCI with ease
• Web Application Firewall, to protect internet facing-endpoints, that are within the customers control/responsibility, from DDoS and other threats, specifically OWASP related attacks

The focus of this post is application security and its components. The other capabilities listed above are also foundational to any service or application deployed on OCI. Please refer to OCI documentation. 

OCI API Gateway

An API gateway is a key component for cloud-native security on OCI that helps secure services on Containers as a Service (CaaS) and Functions as a Service (FaaS) quickly and non-intrusively. This allows developers to build functions and services without having to spend time on the implementation of security. API gateways can be configured to perform authentication and authorization at the time of deployment. 

An API gateway can handle JWT tokens for authentication and authorization with minimal configuration. It can also be configured to handle HTTP Basic Authentication, API Key Authentication, IDCS authentication, and OAuth authentication using Authorizer functions, which are Oracle functions designed to handle authentication requests from the API gateway. The API gateway can log audits through OCI Logging, as well as, limit request rate and request message sizes. It can also be configured for Cross-Origin Resource Sharing (CORS) and specify trusted origins.

An example of an authentication flow using an API gateway is shown below. 

Authentication flow using OCI API gateway.

In this flow, a client application needs to consume services deployed as functions or as containers. The services are protected by an API gateway. The client application has a "Confidential application" configured in IDCS and possesses either client credentials or other forms of authentication such as an OAuth refresh token. The API gateway can be configured with the public key for the trust of the token. Alternately, an API gateway can also fetch the token from the IDCS JSON web key endpoint as shown in step 2.1 of the flow, above. 

1. Client application obtains an access token from IDCS using one of the listed grant types. 
2. The client then prepares a request message and inserts the access token in the "Authorization" header. The API gateway can validate the JWK access token using the public key and, based on the outcome, either accept or reject the request. Steps 2.2 through 2.4 are optional in the flow, for handling advanced authentication and authorization use cases. The API gateway can call an authorizer function, which can validate the token using a secret stored in the OCI vault. The authorizer function can also be designed to validate the token at the IDCS introspection endpoint. 
3. Once the request is authenticated and authorized, the API gateway invokes the service and returns the response to the client application.

Confidential application, an important IDCS feature, is used for API authentication between Fusion SaaS applications and applications deployed on OCI. Confidential applications allow Oracle services and custom applications to authenticate with IDCS and obtain access tokens to authenticate with any service that trusts the tokens issued by the specific IDCS instance. Trust between Fusion SaaS and IDCS is established by importing the signing certificates from IDCS into Fusion.

Here is an example of a confidential application configuration, in IDCS.

In this example, the client application is allowed to authenticate with client credentials or a JWT token, to get an access token. Note that there are also other grant-type options, such as refresh tokens. There are also options to customize the claims in an access token.

In the example above, the token's scope is set so that Fusion SaaS applications will recognize the scope of the token. For more about configuring Confidential applications please refer to IDCS documentation. 

OCI Web Application Firewall

Oracle Cloud Infrastructure Web Application Firewall (WAF) is a cloud-based, Payment Card Industry (PCI) compliant, global security service that can protect applications from malicious and unwanted internet traffic. WAF can protect any internet-facing endpoint, providing consistent rule enforcement across a customer's applications. WAF can protect both web applications and API endpoints. 

Here are some features of WAF most relevant for SaaS extension patterns:

• Access Control – To allow, block or redirect requests based on various criteria such as IP addresses, country/region and user agent type.
• WAF protection rules to protect from known attacks – either 100+ Out-of-box or custom rules.
• Protection from DDoS attacks.

WAF should be an essential protection for integration and extension services for Fusion Applications by customers/partners, and that are accessible over public IPs.

Note: OCI Flexible Load Balancing service now provides built-in WAF capabilities. It is thus possible to reduce the two network hops shown in the above diagram with a single OCI Flexible load balancer. Refer to OCI Flexible Load Balancing documentation for more information.

OCI Identity Domain

Identity Domain  is an integral part of security for Oracle PaaS and services deployed on OCI. This post has addressed how to align instances of IAM with SaaS instances and the use of IAM in federation topologies with Fusion SaaS applications. IAM is also a component of the API security solutions explained thus far. Here are the core features of IAM:

• Advanced Identity and access management
• Single sign-on and federation
• SAML, OAuth, and OpenID Connect support
• Multi-factor authentication (MFA)
• SCIM-compliant REST API
• Adaptive security, Network perimeter, and more

In summary, IAM will be part of most, if not all, patterns for extending SaaS using OCI. There is much more to IAM than the features used for Fusion SaaS integrations and extensions. Please check IAM documentation and blog posts for more information about configuring IDCS and IDCS patterns.

Note: OCI Identity domains provide the capabilities of used to be provided by IDCS. For customers who use IDCS currently, the existing IDCS stripes will be migrated to OCI Identity domains over next several months. Please refer to OCI Identity Domain documentation for more information.

Security Features in Fusion SaaS Service

Fusion SaaS applications are increasingly served from OCI. The security features provided by Fusion SaaS applications are distinct from OCI's security features and must be understood and configured correctly for extensions and integrations created/deployed on OCI. Let us take a look at role-based access control (RBAC), location-based access control, and configuring security for accessing Fusion REST API. Federation of Fusion applications and Fusion and IDCS topology was discussed in earlier sections.

Role-based Access Control (RBAC)

Fusion SaaS applications control access for users through roles assigned to them. Roles are a collection of privileges that can be assigned to users or inherited by other roles for a higher level of privileges. Roles can be created and modified or assigned to users in Security Console. 

There are multiple types of roles. Job roles and Abstract roles can be directly assigned to users. Both can inherit other roles of the same kind or other types of roles, namely, the Duty roles and Aggregate privileges. The roles hierarchy in Fusion applications can be complex. Below is a visual representation of the relationship between types of roles.

Roles can also be designed to restrict a user's extent of access to a particular type of object. For example, a manager can view only his and direct reports' salaries. In ERP, a financial manager must only be able to see the general ledger for his business units. This is also known as data security. HCM provides data roles to limit the extent of data access, using security profiles. In ERP, there are data access sets for this purpose. Data access sets are defined using security contexts, which, for example, can use GL accounts or business units as criteria. 

There is a lot more to RBAC than this overview. Refer to Fusion SaaS application security documentation such as HCM, ERP, or Sales for the specific application for more information. 

Configuring Fusion SaaS for Authentication and Authorization of Extensions 

Here are some common configuration steps applicable for both web extensions and API access. 

• Enable federation between Fusion SaaS and IDCS instance meant for the specific Fusion instance if it is not done already. Refer to Oracle documentation for instructions.
• Synchronize users, roles, and role memberships from Fusion SaaS to IDCS. There are many ways to achieve this synchronization. Refer to Oracle documentation for instructions.
• Assign the users relevant job roles and data access privileges. 

Note that API access using basic authentication does not need federation or synchronizing users. API authentication using third-party application tokens also does not need federation or user synchronization.

REST API authentication

Before client applications on OCI can access Fusion SaaS application REST API, some configuration steps will be necessary.

• Identify users who will invoke the REST API and assign them appropriate job roles and data roles. Create custom roles with the least possible privileges for REST API access. Depending on the application (Financials or HCM, for example), the privileges might differ. Refer to the specific application documentation.
• Import the public certificate of authentication provider under the "API Authentication" section of the Security console, by creating an Oracle API authentication provider. This step is necessary if authentication will be through JWT or SAML tokens, which is recommended for API access triggered from web applications by users. It is acceptable to use system accounts for integration use cases, so long as credentials are encrypted at rest or stored in an OCI vault.

Once the configuration steps are completed, the client applications such as Oracle Functions or applications deployed to containers can use the flow shown.

Web extension authentication

Fusion SaaS users might need to access web extensions deployed to OCI, for example, on Oracle Kubernetes Engine (OKE). The additional task would be to configure the application to use IDCS as the authentication provider. The configuration steps would depend on the type of application runtime used in containers. 

Location-Based Access Control (LBAC)

LBAC provides the ability for customers to restrict access to users and services by IP addresses or IP range. LBAC, for example, can be configured to permit incoming requests only from a customer's on-premise address and from Oracle cloud's IP addresses in a region, which covers customer's tenancy and public IP addresses for customer's services on Oracle cloud. Oracle cloud's IP addresses can be obtained for each region. Refer to the documentation for the list.

The use of LBAC might not be necessary for extending SaaS into OCI. However, many customers do want to allowlist source IP addresses to block traffic from unrecognized sources. 

Certain Fusion SaaS application functions can be excluded from LBAC enforcement, by grouping privileges for functions in a role and then by marking that role as Public. Once a role is marked public, user requests for those capabilities are allowed by LBAC regardless of the origin IP address.

All configurations for LBAC are performed in the Security console. Refer to documentation (and blogs) for more information.

Access Control List (ACL) for Fusion SaaS

The self-service Fusion application provisioning feature provides another opportunity for customers to restrict access to their applications, using users' source IP addresses. Network Access Control Rules section of the self-service Fusion application provisioning page allows customers to specify list of IP addresses and CIDR ranges, from which users can access the application. This access control list is enforced before LBAC is enforced. Unlike LBAC, however, there are no role-based exceptions to this ACL. Below is an example for ACL definition for a self-service instance.

LBAC and ACL are not mutually exclusive features. Customers need to be aware of the order these restrictions are enforced before designing a solution. Please refer to this documentation for an overview of network security options for Fusion applications. 

Note: Self-service provisioning is not available to all customers at the time of this update (May 28th, 2024).  By August of 2024, all customers are expected to have their applications available under FA self-service provisioning page on OCI console.

An Example OCI Extension Pattern with Security Best Practices Applied

Here is an example for an OCI-based extension pattern, with the security tools and techniques discussed in this post applied to it.

This pattern is for a REST-based backend for Visual Builder (VBCS) using OCI Functions. There are several reasons why such a function will be useful for Visual Builder applications. First of all, Visual builder cannot directly invoke SOAP services. Fusion SaaS applications support only SOAP messaging for certain integration services. Next, it is best not to build service orchestrations or data aggregation in VBCS. Such functionality is better left to an Oracle function, which provides a lot of flexibility in programming-language and run time.

In this pattern, a Visual Builder web application needs aggregated data from multiple Fusion SaaS services. An Oracle function performs the aggregation and returns the results to Visual Builder to be displayed to the user.

• API Gateway and WAF are additional services used in this pattern for security. API Gateway enables JWT-token authentication and authorization to Oracle functions, aside from providing an HTTPS frontend to functions.
• A Web application firewall fronts the API gateway endpoint, to protect from DDoS and numerous other potential threats to REST endpoints.
• The API gateway to Oracle functions invocations is secured by IAM policies, in such a way only the gateway can invoke the functions. This ensures that functions can only be invoked through the API gateway. 
• Functions in this case are invoking Fusion SaaS SOAP and REST endpoints. Here, SOAP endpoints authenticate with SAML tokens and REST endpoints authenticate with JWT tokens, as a best practice. The principal of either token is assigned appropriate job roles and data roles. Optionally, LBAC is enabled to ensure that Oracle cloud IPs in the region are permitted to access the endpoints. For another example, check the blog on going cloud-native with HCM integration.

References and Further Information Resources 

• Oracle Fusion SaaS applications
• Oracle Cloud Infrastructure
• Oracle Identity Domain documentation
• Oracle IDCS documentation
• Oracle blogs about IDCS
• Go cloud-native with HCM integration
• Enable Oracle Fusion Applications Cloud Service Federation
• An Introduction to HCM Security in the Cloud
• Oracle CX service security reference
• Oracle Financials Cloud Security Reference for Financials
• Securely Accessing Fusion Applications