Best Practices from Oracle Development's A‑Team

How to bring Azure AD users and groups into IDCS


Any customer using Oracle IDCS with Azure AD as the IDP would want to automate the user and group provisioning process. When Azure AD acts as the IDP, the users are born in Azure AD or are brought into Azure AD from an on-premise repository like AD. Users of the Oracle SaaS or PaaS applications protected with IDCS can be authenticated by Azure AD by setting up the federation trust and user synchronization is a pre-requisite for SSO to work.

For user synchronization, one option is to use IDCS out of the box feature to pull all the Azure AD users/groups/memberships in. More details are available here.

Another option is to push the users/groups/memberships from Azure AD to IDCS. This option provides some flexibility in terms of which users/groups need to be provisioned/synchronized.

IDCS REST APIs comply with the System for Cross-domain Identity Management (SCIM), an open API standard for managing identities across vendors. Azure AD SCIM client can be configured to use this API to create/update/delete users and groups in IDCS.

This blog provides steps to configure this option.


Federation setup between Azure AD as IDP and IDCS as SP is already done and working with a test user created manually.

If you need help with this, you may want to go through a great post here

Getting started

You will need -

1) Azure AD admin access to update the existing IDCS SSO enterprise application.

2) IDCS 19.2.1+ with administrator access to create a new client application.

IDCS Configuration Steps

The following steps show how to create a client application in IDCS which is used by Azure AD to manage users in IDCS.

1) Login to your IDCS  tenancy admin console and create a new confidential application.

Provide a name and click next.

Select Configure this application as a client now

Securely save the Client ID and Client Secret. This will be used later.

In Allowed Grant Types, select Client Credentials.


Add User Administrators role in Grant the client access to Identity Cloud Service Admin APIs 

Save and Activate the application.


Azure AD Configuration Steps

Login to the Azure portal and switch to the appropriate directory and navigate to Azure AD-> Enterprise applications -https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/EnterpriseApps

Open the existing IDCS SSO application configured in Azure AD.

Click on Provisioning and choose Provisioning Mode: Automatic.

For Tenant URL, Provide your IDCS tenant URL in this format- https://idcs-<your tenancy>.identity.oraclecloud.com/admin/v1

Set the Secret Token to a Base64Encode of <client_id>:<client_secret> values noted during application configuration in IDCS in step 1.

Click Test Connection



Update the user and group attribute mappings In Azure AD

For user creation, the mandatory attributes in IDCS are - userName, familyName and a primary email.

Example of IDCS Create User API call with mandatory attributes :


Update the user and group mappings 

Apart from the mandatory user/group attributes, customers may want to add more attributes. The Microsoft document describes how to do this in detail -


Example of Azure AD User Attribute Mapping with a mandatory set of attributes and an additional attribute like givenName


Typically, a federated user should not receive an account activation notification from IDCS. Assuming all the users in IDCS are created via Azure AD, IDCS notifications can be either turned off or an optional isFederatedUser attribute can be set to true at the time of user creation. This indicates that an external IDP holds user credentials and IDCS should not send an account activation email upon user creation. 



Note: At this time, Azure AD only supports adding custom schema extension attributes of type "String" but this may change anytime. So, if Azure AD allows you to add a boolean custom attribute like "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User:isFederatedUser", it's recommended to provision the IDCS users along with this optional attribute set to True.


Example of Group Mapping

Even though additional attributes can be added, the default mapping in Azure AD will work for creating groups in IDCS. 

Scoping and Filtering

A simple way to limit the users and groups being provisioned to IDCS is by selecting the scope :


A granular way is to add a scoping filter while updating the mappings.


Enable the synchronization and verify if the users, groups and group memberships in the scope are being created in IDCS.


Automated user provisioning/synchronization between multi-cloud IAM services like Azure and Oracle is critical for delivering better security and user experience and I am hoping that anyone trying to implement this solution will benefit from this post. 

Join the discussion

Comments ( 1 )
  • John Tomlison Wednesday, May 6, 2020
    I just wanted to mention a "Unauthorized error that can occur if you do not use the proper options when encoding your clientID and Secret. The problem is that Azure requires the clientID and secret to be encoded with UTF-8 and "CRLF Windows" options. We were using the default encoding options of UTF-8 and LF-Unix.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha