Single-Sign-On to Oracle ERP Cloud Banner

Single-Sign-On to Oracle ERP Cloud

More and more enterprises are using Single-Sign-On (SSO) for there on-premise applications today, but what if they want to use SSO for there cloud applications as well?

This blog post is addressing this topic for Single-Sign-On to Oracle ERP Cloud in a hybrid environment.

First of all lets focus on SSO on-premise and introduce some terminology.

A user (aka principal) wants to have access to a particular service. This service can be found at the Service Provider (SP). The provided services are secured so the user needs to authenticate itself first. The Identity Provider (IdP) is able to validate (assert) the authenticity of the user by asking, for instance, the username and password (or using other methods).

So for authentication we always have three different roles: User, Service Provider (SP) and Identity Provider (IdP), as shown below.

Single-Sign-On to Oracle ERP Cloud SSO diagram

For Single-Sign-On we should have a centralized IdP and we should have a standardized way to assert the authentication information.

In an on-premise landscape there is plenty of choice for an IdP. Some common used ones are: Microsoft Active Directory (AD) (closed source), Oracle Identity & Access Management (closed source) and Shibboleth (open source). For now we assume we are using AD.


The most used standard for doing SSO is Kerberos. In that case a Kerberos ticket is asserted by the IdP which is used towards all the Service Providers to be able to login.

This Kerberos method is suited for an on-premise landscape and also suited if the connection to a private cloud is via a VPN (the two are effectively part of the internal network and everything should work ok for the cloud as well). But what if we want to integrate a public cloud such as Oracle Fusion Cloud then things get messy.

Arguably the reason Kerberos isn’t used over the public Internet doesn’t have to do with the security of the protocol itsef, but rather that it’s an authentication model that doesn’t fit the needs of most “public Internet” applications. Kerberos is a heavy protocol and cannot be used in scenarios where users want to connect to services from unknown clients as in a typical Internet or Public Cloud computer scenario, where the authentication provider typically does not have knowledge about the users client system.

The main standards to be able to facilitate SSO for the internet are:

  • OpenID
  • OAuth
  • Security Assertion Markup Language (SAML)

SAML 2.0

Oracle Fusion Cloud is based on SAML 2.0 so let’s go on with this standard for now.
Conceptually the SAML handshake looks like Kerberos; you can also see the different roles for User, SP and IdP and the assertion of a SSO ticket.
Single-Sign-On to Oracle ERP Cloud SAML

Identity Federation

But how can we integrate Kerberos with SAML?
Now a different concept comes in: Identity Federation. This means linking and using the identity of a user across several security domains (on-premise and public cloud). In simpler terms, an SP does not necessarily need to obtain and store the user credentials in order to authenticate them. Instead, the SP can use an IdP that is already storing this. In our case the IdP is on-premise (Active Directory for example) and the SP is the Oracle Fusion Cloud application.
Now there are two things to be done:
  • The on-premise Kerberos ticked should be translated to SAML. Because we want SSO.
  • There is need for trust between IdP en SP. Only trusted security domains can access the SP. Trust configuration should be done at both sites (on-premise vs cloud)
Translation of Kerberos ticked is performed by a Security Token Service (STS). This is the broker that sits between a SP and the user. An STS is an issuer of security tokens. “Issuer” is often a synonym of an STS. STS’s can have different roles: as IdP when they authenticate users or as Federation Provider (FP) when they sit in the middle of a trust chain and act as “relying parties” for other IdPs.
In our case the STS translates Kerberos to SAML and Microsoft Active Directory Federation Server (ADFS) and Oracle Identity Federation Server (part of Oracle Identity Governance Suite) are examples of doing this.
So the picture look like this now:
Single-Sign-On to Oracle ERP Cloud Cloud SSO 1


But how is the Trust achieved?
Trust is just metadata about the SP and the IdP. So the metadata from the IdP should be uploaded in Oracle ERP Cloud and visa versa.When you create metadata for the IdP, the IdP entity is added to a circle of trust. A circle of trust is used to group SP’s and IdP’s in a secure, trusted environment. Other remote provider entities can be added to the circle of trust.
Metadata is defined in XML. A SP uses the Metadata to know how to communicate with the IdP and vise versa. Metadata define things like what service is available, addresses and certificates:
  • Location of its SSO service.
  • An ID identifying the provider.
  • Signature of the metadata and public keys for verifying and encrypting further communication.
  • Information about if the IdP wants the communication signed or encrypted.
There is no protocol how the exchange is done, but there are no secret information in the metadata so the XML can be freely distributed by mail or published in clear text on the Internet.
It is however highly recommended that the metadata is protected from unauthorized modification, this could be a good start on a Man-In-The-Middle attack.
The integrity of the Metadata could be protected using for example digital signatures or by transporting the metadata using some secure channels.
Metadata could contain lots of other information. For a full description have a look at the SAML specifications

Oracle ERP Cloud Security

Application Security in Oracle ERP Cloud consists of two parts:
  1. Oracle Identity Management (OIM) running in the cloud (Oracle Identity Federation is part of this).
  2. Authorization Policy Manager (APM).
Oracle Identity Management is responsible for the user accounts management. Authorization Policy Manager is responsible for the fine grained SaaS role mapping (aka Entitlements).
See this blog post from Oracle how this works:
Remark: the application security in Oracle ERP Cloud will change with R12 and will benefit from the following new capabilities:
  • Separation between OIM and APM is no longer available. A new simplified Security Console will contain both.

Single-Sign-On to Oracle ERP Cloud R12

  • Configuration of SSO integration (with IdP) is simplified and can be performed from a single screen.
  • REST API’s based on SCIM (System for Cross-Domain Identity Management) 2.0 are available for Identity Synchronization with IdP.
Another remark: Oracle Identity Cloud Service is released in Q1 2017. Integration with Oracle ERP Cloud is not the case yet because Identity Federation functionality is not implemented yet. The release date isn’t clear, so we have to deal with the functionality presented above.

Configuring SSO for Oracle ERP Cloud

 For SSO the following aspects should be taken into account:
  • Users and Entitlements
  • Initial upload of identities and users
  • Identity and user Synchronization
  • Exchange of SP and IdP metadata

Users and Entitlements

Before going into this I must explain the difference between users and employees.

  • When talking about users we mean the user login account. As explained before these accounts are the domain of IAM.
  • Users have access rights based on Role Based Access Controls (RBAC). Also IAM is handling this.
  • Users have entitlements to use particular ERP functionality. This is handled in APM.
  • When talking about employees we mean the business employee with it’s associated business job. This is the domain of Oracle HCM Cloud (even when you don’t have a HCM full-use license). An employee can access Oracle ERP Cloud when it’s having an user account in IAM and the proper entitlements in APM.

Initial user upload

To establish SSO between the customer’s on-premises environment and the Oracle ERP Cloud environment, the customer must specify which identity attribute (aka GUID) (user name or email address) will be unique across all users in the customer’s organization. The SAML token should pass this attribute so the SP could determine which user is asserted (remember the first picture in this blog post).

But before this could work the SP should have all users loaded. This is a initial step in the Oracle ERP Cloud on-boarding process.
Currently (Oracle ERP Cloud R11) the following options are available:
  • If running Oracle HCM Public Cloud, you may need to use HR2HR Integration
  • If running Non-HCM Public Cloud, use Spreadsheet Upload [Document Note 1454722.1] or if you are running CRM Public Cloud, use the CRM upload utility for HCM employees. You could also manually enter the employee.

Do the following tasks to load the initial user data into Oracle ERP Cloud:

  1. Extract user data from your local LDAP directory service to a local file by using the tools provided by your LDAP directory service vendor.
  2. Convert the data in the file into a format that is delivered and supported by Oracle ERP Cloud.
  3. Load the user data into Oracle ERP Cloud by using one of the supported data loading methods.

Data loaders in Oracle ERP Cloud import data in the CSV format. Therefore, you must convert user data extracted from your local LDAP directory into the CSV format. Ensure that the mandatory attributes are non-empty and present.

From Oracle ERP Cloud R12 the initial load can also be performed by using the SCIM 2.0 REST API’s. For details about this see:

Identity and user Synchronization

The IdP should always have the truth about the users and business roles. So there should be something in place to push them to the Oracle ERP Cloud.

For R12 the SCIM REST API’s are the best way to do that. For R11 it’s a lot more complicated as explained below.

Now the concept of employee and job comes in again. As explained earlier in this blog post this is the domain of Oracle HCM Cloud (which is also part of Oracle ERP Cloud).

Oracle HCM Cloud is having REST API’s for read and push of Employee and Job data to Oracle HCM Cloud:

  • GET /hcmCoreApi/resources/
  • POST /hcmCoreApi/resources/
  • PATCH /hcmCoreApi/resources/{empsUniqID}
  • GET /hcmCoreSetupApi/resources/
  • GET /hcmCoreSetupApi/resources/{jobsUniqID}

For more details about these see (which are also available in R11) see:

But how can we provision IAM/APM? For that Oracle HCM Cloud have standard provisioning job:

  • Send Pending LDAP Requests: Sends bulk requests and future-dated requests that are now active to OIM. The response to each request from OIM to Oracle Fusion HCM indicates transaction status (for example, Completed).
  • Retrieve Latest LDAP Changes: Requests updates from OIM that may not have arrived automatically because of a failure or error, for example.

Single-Sign-On to Oracle ERP Cloud IAM provisioning jobs

For details see:

Now the problem could arise that an administer has changed user permissions in ERP Cloud (HCM or IAM/APM) which are not reflected in the IdP (which should always reflect the truth), so these are out-of-sync.

To solve this the IdP should first read all employee and job data from Oracle HCM Cloud and based on that creates the delta with it’s own administration. This delta is pushed to Oracle HCM Cloud so all manually changes are removed. This synchronization job should be performed at least every day.

The whole solution for Identity and user synchronization for R11 could look like this:

Single-Sign-On to Oracle ERP Cloud Identity Sync 1


Exchange metadata for SSO

In R11 of Oracle ERP Cloud the exchange of SAML metadata for SSO is a manual process. In R12 there is a screen to do this. So for R12 skip the rest of this blog.
For R11, generation of SP metadata.xml (to setup the Federation for IdP) and upload of your IdP metadata.xml into the SP is performed by the Oracle Cloud Operations team. To start the integration process you should create a Service Request and provide the following information:
  • Which type Federation Server is used on-premise.
  • Which SaaS application you want to integrate.
  • How many users will be enabled.
  • URL’s for IdP production and IdP non-production.
  • Technical contacts.

The following should also be taken into account (at both sites):

  • The Assertion Consumer Service URL of the SP, where the user will be redirected from the IdP with SAML Assertion.
  • The Signing Certificate corresponding to the private key used by the SP to sign the SAML Messages.
  • The Encryption Certificate corresponding to the private key used by the SP to decrypt the SAML Assertion, if SAML encryption is to be used.
  • The Logout service endpoint.
The Oracle Cloud Operations team document delivers a document how to configure the on-premises IdP (Microsoft Active Directory Federation Server (ADFS) 2.0 or Oracle Identity Federation Server 11g).
Be aware that the Oracle Cloud Operations team needs two weeks as least to do the configuration in Oracle SSO Cloud.
For detailed information about this see Oracle Support Document: Co-Existence and SSO: The SSO Enablement Process for Public Cloud Customers (Doc ID 1477245.1).


  1. vinod kumar January 9, 2020
  2. Mike December 22, 2018
  3. Foued March 22, 2017