Confusion Around the number of IDCS Instances

June 2, 2020 | 2 minute read
Mike Muller
Cloud Solution Architect
Text Size 100%:
Introduction

We often hear questions from customers about the number of Identity Cloud Service (IDCS) instances that exist in their tenancy.  There is confusion around why there are multiple instances and what they are intended to be used for.  This blog attempts to answer these questions.

Why So Many Instances?

Whenever a customer purchases a Fusion Applications SaaS or PaaS service, that service instance will also provision an associated IDCS instance.  For instance, if a customer was to purchase an HCM SaaS service for Test, an HCM SaaS service for Production, an Integration Cloud service for Test and an Integration Cloud service for production, then they would also see four additional IDCS service instances in their cloud account.

How do I know which IDCS instance goes to what?

When looking at the service instances under your account’s “My Services” page, in the above example you’ll see four instances of the Identity Cloud Service, each with a different name.  The IDCS instances that are automatically provisioned as part of an FA SaaS or PaaS instance provisioning will be named by appending “idcs” to the name of the service instance.  For example, if you provisioned an Integration Cloud service with the name “oictest”, the associated IDCS instance will be named “oictestidcs”.

What is the intended use of these instances?

Each service instance gets an associated IDCS instance in order to manage user access and privileges independently for that instance.  This allows the cloud account administrator to define which users can access a particular service instance and what roles/privileges that user has for that instance.  For example, in an FA SaaS test instance user x may have access to a higher set of privileges for testing than they do in the production instance where as user y may have access to a PaaS test instance, but not the production instance.

It is also possible to federate these IDCS instances and synchronize users/groups across them as desired.  Find out more about how to set that up here and here. They may also be federated with an external Identity provider.  However, be aware that these IDCS instances are granted a Foundation license and some federation or user sync scenarios may require a Standard license.  The included functionality by license type can be found here.

 

Mike Muller

Cloud Solution Architect


Previous Post

ISV Implementation Details - Part 4A - Linux Clustering with Pacemaker and Corosync

Tal Altman | 8 min read

Next Post


CICD - Using CSM Rest API's for Sandbox Migration

Mithun Devkate | 4 min read