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:
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.
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:
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.