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.

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.

Kerberos

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

Identity Federation

• 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)

Trust

Oracle ERP Cloud Security

1. Oracle Identity Management (OIM) running in the cloud (Oracle Identity Federation is part of this).
2. Authorization Policy Manager (APM).

• Separation between OIM and APM is no longer available. A new simplified Security Console will contain both.

Configuring SSO for Oracle ERP Cloud

• 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).

• 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: https://docs.oracle.com/cd/E52734_01/oim/OMDEV/scim.htm#OMDEV5526

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/11.12.1.0/emps
• POST /hcmCoreApi/resources/11.12.1.0/emps
• PATCH /hcmCoreApi/resources/11.12.1.0/emps/{empsUniqID}
• GET /hcmCoreSetupApi/resources/11.12.1.0/jobs
• GET /hcmCoreSetupApi/resources/11.12.1.0/jobs/{jobsUniqID}

For more details about these see (which are also available in R11) see: https://docs.oracle.com/cloud/latest/globalcs_gs/FARWS/Global_HR_REST_APIs_and_Atom_Feeds_R12.html

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.

For details see: http://docs.oracle.com/cloud/farel8/common/OCHUS/F1210304AN1EB1F.htm

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:

Exchange metadata for SSO

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