Cloud Security Perspectives and Insights

The recommended approach for using external identities with Oracle Cloud

Paul Toal
Distinguished Solution Engineer - Cyber Security

Oracle has a comprehensive set of cloud services that extends across SaaS, PaaS, and IaaS.

If you are using Oracle Cloud, then chances are, you are likely using multiple services. For example, you may be using an Oracle SaaS application such as Financials and you want to extend it using one or more of our PaaS services. Or, you may be hosting a custom application on IaaS and using PaaS services to deliver that application’s front-end.

Irrespective of which services your project is using, the topic of Identity and Access Management (IAM) will surface. How do you integrate the different services with your existing identity management? I have talked before about how to deliver a project and cover your IAM needs without delivering a full IAM programme, but at a practical level, what should that look like within Oracle Cloud?

I am often involved in conversations where a customer is onboarding Oracle Cloud and wants to integrate it with their existing IAM platform. The scenario is a common one, where the customer is using multiple Oracle Cloud services and wants to, as a minimum, deliver single sign-on (SSO) to their end users, but also, ideally, manage users and their identities within Oracle Cloud from their existing platform. The diagram below shows a common scenario that I am presented with.

In this example:

  • Oracle SaaS represents ERP, or HCM etc,
  • Oracle PaaS covers cloud services like Analytics or Visual Builder. These are usually tightly-coupled to Oracle Identity Cloud Service (IDCS) as their underpinning IAM platform.
  • Oracle IaaS is the Oracle Cloud Infrastructure (OCI) platform where IaaS resources are created and managed
  • Custom is usually some kind of customer-installed, custom application running on OCI, e.g. a NodeJS application, or legacy apps.

So, how do you integrate these services with your existing IAM platform? There are a couple of different approaches you can take.

Option 1 – Point integrations

The first approch is to create multiple, point integrations between your identity provider (IdP) and the various services you are using within Oracle Cloud. Here, open standards are your friend as the different services within Oracle support standards like SAML. This would produce a solution looking like this:

Whilst this is one feasible approach, it has a number of challenges. Here are some of the points you need to consider.



  • You are maintaining multiple points of trust between Oracle Cloud and your IdP, leading to greater maintenance.
  • If you have multiple IdPs, this can present a challenge to some target applications
  • The user may have a poor user experience as they navigate various logon screens
  • Your custom app may not support open standards
  • Your IdP recognises each service as separate, so you can apply different authentication policies to different target applications at your IdP.






There is another, and in my view, much cleaner approach.

Option 2 – Single point of trust

The second approach, and my preferred option, is to architect your solution to enable a single point of integration and trust between your external identity provider (IdP) and Oracle Cloud by extending the use of Identity Cloud Service (IDCS), which would look like this:

All Oracle Cloud tenancies come with IDCS, and it is already linked to many of the services you will be using. For example, it is pre-integrated with OCI and, as mentioned above, many Oracle PaaS services depend on IDCS and are therefore pre-integrated with it also. Therefore, extending its use across the rest of your Oracle services is straightforward. It is just a case of following one of the documented integration guides (e.g., here is how you integrate Oracle SaaS applications with IDCS).

The approach shown in option two provides a number of benefits, including:

  • A single point of trust between your IdP and Oracle Cloud, so one point of integration for you to maintain both from an SSO and user lifecycle management perspective.
  • Open standards SCIM support for simplified, integrated user lifecycle management.
  • Active Directory (AD) bridge for managing your IDCS user and groups from your existing AD.
  • Out-of-the-box integrations for many enterprise applications and services, including strong support for Oracle applications and services.
  • Centralised policy control over which applications a user can access within Oracle Cloud.
  • Rich IAM capabilities in IDCS to complement and/or enrich your existing IAM platform, including:
    • App Gateway – for integrating legacy apps that don’t support standards
    • Adaptive Security – for layering risk-based access into the authentication flow
    • Multi-factor authentication – strengthening security through a wide range of factors, including FIDO2 to support passwordless authentication.
    • Multiple IdP support - Removes any limitations around the number of IdPs supported by target applications.
    • Provisioning and synchronisation of identities to/from target applications.

N.B. Some features of IDCS require an IDCS subscription.

For me, option 2 architecturally provides a much cleaner solution compared to the first option. It also abstracts any changes to your external IdP away from the individual cloud services. So, for example, if you are in the process of migrating from an on-premises IdP to a cloud IdP, your Oracle Cloud services don’t need to care. Or, if you acquire a new company with a separate IAM platform, again, you don’t need to worry about re-configuring your individual Oracle Cloud services. You only make the change within IDCS. Plus, the user experience is far more consistent across the solution.

If you want to find out more about Oracle Identity Cloud Service, you can read about it here, or you can always sign up for a Oracle Cloud free trial.

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.