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 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.
The most comomly used SAML login flows are Service Provider Initiated Login and Identity Provider Initiated Login as shown below.
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.
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.
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 components of this scenario are:
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).
To setup this scenario Oracle Cloud Support and the Customer work together to create a operational scenario.
To start the setup, the on-premise Identity Provider must be configured to fulfill these requirements:
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:
|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 2100578.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).
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.
The general process works as follows:
|Step||Oracle SaaS||On-premise Environment|
|1.||Setup Extraction Process|
|3.||Convert Data into Identity Store Format|
|4.||Import Data into Identity Store|
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|
|2||Convert data into supported file format|
|3||Load user data using supported loading methods|