Introduction
To get you easily started with Oracle Cloud offerings, they come with their own user management. You can create users, assign roles, change passwords, etc.
However, real world enterprises already have existing Identity Management solutions and want to avoid to maintain the same information in many places. To avoid duplicate identities and the related security risks, like out of sync passwords, outdated user information, or rogue user accounts of locked accounts, single sign-on solutions are mandatory.
This post explains how to setup Federated Single Sign-on with Oracle SaaS to enable users present in existing Identity Management solutions to work with the Oracle SaaS offerings without additional user setup. After a quick introduction to Federated Single Sign-on based on SAML, we explain the requirements and the setup of Oracle SaaS for Federated Single Sign-on.
Federated Single Sign-on
Federated Single Sign-on or Federated SSO based on SAML Web Browser Single Sign-on is a widely-used standard in many enterprises world-wide.
The SAML specification defines three roles: the principal (typically a user), the Identity Provider, and the Service Provider. The Identity Provider and the Service Provider form a Circle of Trust and work together to provide a seamless authentication experience for the principal.
SAML Login Flows
The most comomly used SAML login flows are Service Provider Initiated Login and Identity Provider Initiated Login as shown below.
Service Provider Initiated Login
The Service Provider Initiated Login is the most common login flow and will be used by users without explicitely starting it. Pointing the browser to an application page is usually all that is needed.
Here the principal requests a service from the Service Provider. The Service Provider requests and obtains an identity assertion from the Identity Provider and decides whether to grant access to the service.
Identity Provider Initiated Login
SAML allows multiple Identity Provider configured for the same Service Provider. Deciding which of these Identity Providers is the right one for the principal is possible but not always easy to setup. The Identity Provider Initiated Login allows the principal to help here by picking the correct Identity Provider as a starting point. The Identity Provider creates the identity assertion and redirects to the Service Provider which is now able to decide whether to grant access to the service.
Oracle SaaS and Federated SSO
Here Oracle SaaS acts as the Service Provider and builds a Circle of Trust with a third-party, on-premise Identity Provider. This setup applies to all Fusion Applications based SaaS offerings (like Oracle Sales Cloud, Oracle HCM Cloud, or Oracle ERP Cloud) and looks like this.
The setup requires a joint effort of the customer and Oracle Cloud Support.
Scenario Components
The components of this scenario are:
- Oracle SaaS Cloud (based on Fusion Applications, for example, Oracle Sales Cloud, Oracle HCM Cloud, Oracle ERP Cloud)
- Any supported SAML 2.0 Identity Provider, for example:
- Oracle Identity Federation 11g+
- Oracle Access Management 11gR2 PS3+
- AD FS 2.0+
- Shibboleth 2.4+
- Okta 6.0+
- Ping Federate 6.0+
- Ping One
- etc.
The list of the supported SAML 2.0 Identity Providers for Oracle SaaS is updated regularly, and is available as part of the Fusion Applications Technology: Master Note on Fusion Federation (Support Doc ID 1484345.1).
Supported SAML 2.0 Identity Providers
The Setup Process
To setup this scenario Oracle Cloud Support and the Customer work together to create a operational scenario.
Setup of the On-Premise Identity Provider
To start the setup, the on-premise Identity Provider must be configured to fulfill these requirements:
- It must implement SAML 2.0 of the Federation protocol.
- The SAML 2.0 browser artifact SSO profile has been configured.
- The SAML 2.0 Assertion NameID element must contain one of the following:
- The user’s email address with the NameID Format being Email Address
- The user’s Fusion uid with the NameID Format being Unspecified
- All Federation Identity Provider endpoints must use SSL.
Setup of the Oracle SaaS Cloud Service Provider
Once the on-premise Identity Provider has been configured successfully, the following table outlines the process to request the setup of Oracle SaaS as Service Provider for Federated SSO with the customers on-premise Identity Provider:
| Step | Customer | Oracle |
|---|---|---|
| 1. | File a Service Request to enable the required Oracle SaaS instance as Service Provider. The Service Request must follow the documented requirements. (See Support Doc ID 1477245.1 or 1534683.1 for details.) |
|
| 2. | Approves the Service Request | |
| 3. | Receives a document that describes how to configure the on-premise Identity Provider for the Service Provider. | |
| 4. | When the conformance check has been done successfully, the Identity Provider Metadata File as XML file must be uploaded to the Service Request. | |
| 5. | Configures the Service Provider in a non-production SaaS environment. When this is completed the Service Provider Metadata will be attached to the Service Request as an XML file for the customer. This file includes all the required information to add the Service Provider as a trusted partner to the Identity Provider. | |
| 6. | Download the Service Provider metadata file and import it into the Identity Provider. | |
| 7. | Adds the provided Identity Provider metadata to the Service Provider setup. | |
| 8. | After the completion of the Service Provider setup, publishes a verification link in the Service Request. | |
| 9. | Uses the verification link to test the features of Federated SSO.
Note: No other operations are allowed during this verification. |
|
| 10. | When the verification has been completed, update the SR to confirms the verification. | |
| 11. | Finalize the configuration procedures. | |
| 12. | Solely responsible for authenticating users. |
When Federated SSO has been enabled, only those users whose identities have been synchronized between the on-premise Identity Provider and Oracle Cloud will be able to log in. To support this, Identity Synchronization must be configured (see below).
Identity Synchronization
Federated SSO only works correctly when users of the on-premise Identity Store and of the Oracle SaaS identity store are synchronized. The following sections outline the steps in general. The detailed steps will be covered in a later post.
Users are First Provisioned in Oracle SaaS
The general process works as follows:
| Step | Oracle SaaS | On-premise Environment |
|---|---|---|
| 1. | Setup Extraction Process | |
| 2. | Download Data | |
| 3. | Convert Data into Identity Store Format | |
| 4. | Import Data into Identity Store |
Users are First Provisioned in On-Premise Environment
It is very common that users are already exiting in on-premise environments. To allow these users to work with Oracle SaaS, they have to be synchronized into Oracle SaaS. The general process works as follows:
| Step | Oracle SaaS | On-premise Environment |
|---|---|---|
| 1. | Extract Data | |
| 2 | Convert data into supported file format | |
| 3 | Load user data using supported loading methods |
References
- Wikipedia: Security Assertion Markup Language
- A-Team Chronicles: SAML is good, but it s no replacement for WAM
- Product Documentation Oracle Sales Cloud: Securing Oracle Sales Cloud Chapter 15, Implementing Federated Single Sign-On
- Fusion Applications Technology: Master Note on Fusion Federation (Support Doc ID 1484345.1)
- Co-Existence and SSO: The SSO Enablement Process for Public Cloud Customers (Support Doc ID 1477245.1)
- Cloud Service Requests and Fulfillment for Oracle HCM Cloud Service (Support Doc ID 1534683.1)
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission