Configuring SAML Federation between Oracle Identity Cloud Services and MS Azure AD


The intent of this post is describing the mechanics for configuring very basic SAML Federation between Oracle Identity Cloud Services (IDCS) and Microsoft Azure AD. The scenario in mind is having Azure AD as an Identity Provider to IDCS. The required configuration in Azure AD is essentially the same as presented in Paulo’s excellent post, where he describes configuring Federation between Oracle Public Cloud’s Shared Identity Management (SIM) and Azure AD, with the same scenario in mind. However, since some screens in Azure AD have changed a bit, I am going through the Azure AD screens again here.

For implementing this, an Azure AD Premium subscription was used. At the time of this writing, you can get one 30-day free trial at

Aug/16/2018 Update: It has been reported that this post has been successfully used for configuring SAML Federation between IDCS and Azure AD Standard as well.

Azure AD Configuration

1. Navigate to Azure’s Portal page.

Click the “Azure Active Directory” link, on the left pane:



2. Create an Enterprise Application for Oracle IDCS

Click on “Enterprise Applications” link.



Click on the “New Application” button.



Since Oracle IDCS is not a pre-built integration in Azure AD, you have to create it manually. Choose any of the categories on the left pane (I’ve picked All) and then click on “Non-gallery application button”. This is the time when Azure will require a Premium trial. Follow Azure’s wizard to activate that.

Once your Premium trial is activated, you should be able to enter the application name. Type in “Oracle IDCS” and hit the “Add”  button.



3. Configure Oracle IDCS as a Service Provider

With the “Oracle IDCS”  application created, click on the “Single Sign-on” link on the left pane. This is where we get to the real integration details:

a. Pick “SAML-based Sign-on” in Single Sign-on Mode combo box.

b. SAML Version must be SAML 2.0.

c. “Identifier” MUST correspond to Oracle IDCS SAML Provider ID. You get this value when configuring IDCS, so it’s ok to enter a temporary value.

At runtime, the value configured here is inserted into the SAML assertion as the “Audience” element, which gets validated by IDCS.

d. “Reply URL” MUST correspond to the IDCS endpoint that is going to process the incoming SAML assertions sent by the Azure AD. This is also commonly known as the SAML Assertion Consumer Service. You also get this value when configuring IDCS, so it’s ok to enter a temporary value. However, be aware that IDCS will tell you that the endpoint value is https://<IDCS_host>/fed/v1/sp/sso, where <IDCS-host> is the IDCS host name exposed by Oracle Cloud.

e. In “User Identifier”, pick the attribute that Azure AD will insert as the Subject Name Identifier in the SAML Assertion. Here, I am using “user.mail”, meaning the user email address.

Such identifier MUST exist within Oracle IDCS.

Note: Azure AD’s out of box configuration makes user.userprincipalname as the “User Identifier”. Leaving it like that will make Azure AD injecting a Name Identifier like “” in the SAML assertion. Such identifier probably won’t exist in IDCS identity store.

f. Click on the Metadata XML link for exporting Azure AD metadata for SAML Federation. This file will be imported into IDCS.




5. Assign users to Oracle IDCS application.

Only these users will be able to login into Azure AD and be federated to Oracle IDCS. Click “Users and groups” link on the left pane and then “Add user” button on the right. Follow the wizard for having the users granted to the application.



IDCS Configuration

IDCS configuration is pretty much about creating an usual Identity Provider (nothing fancy really), as it would be done for any other Identity Provider than Azure AD. Here are the steps.

Note: As a pre-requisite, make sure users in Azure AD also exist in IDCS and that the IDCS authenticating attribute properly maps to the Subject Name Identifier in the SAML assertion that is created by Azure ID. In the example implemented on this post, the authenticating attribute is the user email address.

A quick way of creating users in IDCS is via IDCS Console. On IDCS Home Page, click “Users”, then the “Add” button for entering user data. Marking the checkbox “Use the email address as the user name” is not a requirement, unless, obviously, you deliberately want that. That’s my case, by the way.



Ok, with users created, let’s now get the Identity Provider created.

1. Identity Provider Basic Info 

On IDCS Home Page, at the bottom, click the “Manage IDPs” link within the Single Sign-On area on the right.



Click on “Add SAML IDP” button.



Enter Name and Description. Click Next.



2. Import Azure AD metadata file into IDCS

Check “Include Signing Certificate” only if you want IDCS to include its signing certificate in SAML requests, so they can be verified by Azure AD. In the setup described in this post, I’ve left that unchecked. Click Next.



3. Attribute Mapping

In the setup below, you’re defining that IDCS, at runtime, should try to match the incoming “Name ID” value in the SAML Subject to the “Username” attribute on its user store. In my IDCS instance, the username attribute is the user’s email address. And since Azure AD is going to send IDCS the user’s email address in the SAML assertion, the “Requested NameID Format” is “Email Address”. Click Next.



4. IDCS Metadata Download

At this step, there’s no need to Download the Service Provider Metadata, since the SAML configuration is done manually in Azure AD.

Click Next for testing.

Note: On this page, do make a note of “Provider ID” and “Assertion Consumer Service URL”. Their values MUST be entered in Azure AD configuration as “Identifier” and “Reply URL” at steps 3c and 3d, as described previously in this document.




5. Test the Integration

We’re almost set. Click “Test Login” button.



A new tab should be opened and the browser redirected to Azure AD login screen for authentication.



If right credentials are provided, the browser should be redirected back to IDCS test result page.



6. Activate the Identity Provider

On the last screen of the Identity Provider creation, click “Activate” button and then “Finish”. “AzureAD” Identity Provider must now appear in the list of configured Identity Providers.

If you want it to show up on IDCS login page as one available Identity Provider, click the “Menu”  icon on the far right of “AzureAD” row and select “Show on Login Page” option.



For a full fresh test, open up a private browser session and navigate to /ui/v1/myconsole in IDCS. IDCS will prompt the user for authentication, showing all configured options, besides the local login option.



Click “AzureAD” and enter your credentials on Microsoft’s web site. If they are correct, the browser will be redirected back to IDCS /ui/v1/myconsole.


Ending Remarks

In this post I’ve presented the steps for configuring basic SAML Federation between Oracle IDCS and MS Azure AD as the Identity Provider. At the end, we were able to test it for an IDCS native protected resource (/ui/v1/myconsole).

But what if the service being protected is external to IDCS, like HCM Cloud, OBIEE, SalesForce, Dropbox or a custom SAML-based service? Not a problem, in such cases, IDCS is seen by these external services as an Identity Provider, while delegating authentication to yet another Identity Provider, Azure AD, in our use case. At runtime, access to one of those external services triggers federation to IDCS, which in turn triggers federation to Azure AD. Ultimately, the end user authenticates in Azure AD and gets access to the required service. This gets us into the realm of a Federation Proxy model, which has been described by my colleague Vinay Kalra on his post named Identity Cloud Service: Configuring SAML.

Add Your Comment