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 guarantee security end-to-end. The focus of this post is on integrations and extensions for Oracle Fusion SaaS applications (aka. Fusion SaaS) on Oracle Cloud Infrastructure (OCI), specifically, HCM and ERP. The best practices shared in this post can generally be extended to other Oracle SaaS applications.
Here is a high-level view of the cloud services and key security features of each service.
Each application or domain has its 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. Fusion SaaS services provide features such as Role-based access control. However, certain security features span applications and must be understood and implemented across applications in a solution. Here are some essential security features for integrations and extensions.
Identity federation enables the trust of users across applications and establishes a single point of security control. The most familiar aspect of a federation is that it helps eliminates 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 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 essential for 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.
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 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 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.
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.
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 service.
Fusion cloud applications and 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 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:
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.
An API gateway is a key component for cloud-native security on OCI that helps secure services on CaaS and 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 API gateway. An API gateway can log audits through OCI Logging, and, 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.
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 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.
Oracle Cloud Infrastructure Web Application Firewall (WAF) is a cloud-based, Payment Card Industry (PCI) compliant, global security service that protects 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 application and API endpoints.
Here are some features of WAF most relevant for SaaS extension patterns:
WAF should be an essential part of integration and extension services on OCI that are accessible over public IPs.
Identity Cloud service is an IDaaS offering that is an integral part of security for Oracle PaaS and services deployed on OCI. This post has addressed how to align instances of IDCS with SaaS instances and the use of IDCS in federation topologies with Fusion SaaS applications. IDCS is also a component of the API security solutions explained thus far. Here are the core features of IDCS:
In summary, IDCS will be part of most, if not all, patterns for extending SaaS using OCI. There is much more to IDCS than the features used for Fusion SaaS integrations and extensions. Please check IDCS documentation and numerous blogs for more information about configuring IDCS and IDCS patterns.
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 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.
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.
Here are some common configuration steps applicable for both web extensions and API access.
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.
Before client applications on OCI can access Fusion SaaS application REST API, some configuration steps will be necessary.
Once the configuration steps are completed, the client applications such as Oracle Functions or applications deployed to containers can use the flow shown.
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.
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 whitelist source IP addresses to block traffic from unrecognized sources.
Certain Fusion SaaS application functions can be excluded from LBAC enforcement, but 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.
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 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 Build to be displayed to the user.
For another example, check the blog on going cloud-native with HCM integration.