SSO lets users log in to one domain and access another domain without logging in again.
Oracle Cloud uses the SAML 2.0 protocol to integrate internal and external users. Oracle Cloud doesn’t support all features of this standard.
In cases where a user is accessing Oracle Cloud resources from the Oracle Cloud, to leverage SSO only the Oracle Access Manager component WebGate is required because all the resources the user wants to access are in the same domain.
Federated web SSO leveraging SAML is required when users are attempting to access Oracle Cloud resources from a different Internet domain using Oracle’s or a third-party SAML-compliant identity management system such as Oracle Access Manager or Microsoft Active Directory Federation Services.
Enabling SSO for your Oracle Cloud users provides these advantages:
It eliminates the need for two different passwords for two different accounts (on premises and cloud).
Because there’s only a single password, users are more likely to use a strong password and keep it confidential.
It reduces failed login attempts and may reduce the frequency of password resets, thereby improving the user's experience.
Enabling SSO centralizes authentication and authorization.
Oracle Cloud SSO also includes a failback mechanism. If SSO becomes inoperable, then administrators can log in to their identity domains directly, bypassing the SSO identity provider. This is necessary to resolve problems.
The HTTP redirect binding defines how SAML requests and responses are transported using HTTP redirect messages (HTTP 302 status code responses).
The HTTP POST binding defines how SAML protocol messages can be transported with the base64-encoded content of a form control within an HTML form.Base64 is an encoding and decoding technique used to convert binary data to an ASCII string.
The HTTP artifact binding defines how a reference or artifact to a SAML request or response is transported over HTTP. The artifact (a very small representation of a full-blown SAML assertion) can be embedded in a URL as a query string parameter, or it can be placed in a hidden form control.
In SIM, the HTTP redirect binding is used to deliver the SAML authentication request message to the identity provider and the HTTP POST binding is used to return the SAML response message containing the SAML assertion to the service provider (for example, SIM in this case).
The HTTP artifact binding is rarely used. Although, it’s much more secure than the HTTP POST binding. The HTTP artifact binding has a bigger overhead, because for example, a back channel communication has to take place between the identity provider and service provider, which requires additional pieces of infrastructure. This is one of the reasons why companies tend to avoid using SAML artifacts.
SAML also defines profiles. SAML profiles define how SAML assertions, SAML protocols, and SAML bindings are combined in particular use cases. For example, SIM uses the web browser SSO profile, which is an SSO mechanism for web browsers using the Authentication Request Protocol in combination with the HTTP redirect, POST, and Artifact bindings as described.
The SAML implementation in Oracle Cloud has the following limitations:
It supports only POST profile.
It supports only the email address or the user ID as the mapping attribute.
It supports only SAML 2.0. Identity providers that use either SAML 1.1 or SAML 1.0 are not compatible.
User Login with SSO
When SSO is enabled, the identity provider performs authentication for Oracle Cloud services.
When you attempt to log in to an Oracle Cloud service by selecting Sign in with your company ID on the login page , you’re redirected to the identity provider, which performs the authentication. Here’s the sequence of events:
In the browser, you try to reach an Oracle Cloud service. On the login page, the user selects Sign in with your company ID.
The service provider, Oracle Cloud, generates a SAML authentication request, encodes it, and embeds it into a URL, along with state information and the encoded URL of Oracle Cloud.
Oracle Cloud sends a redirect message to your browser, using the SSO URL. This URL redirects your browser to the identity provider.
The identity provider decodes and extracts the information from the URL, and then prompts you for credentials and authenticates you.
The identity provider generates a SAML response containing your user name, digitally signed with the identity provider’s public and private keys.
The identity provider encodes the SAML response and state information, and returns it to the browser. The browser then sends this information to Oracle Cloud.
Oracle Cloud verifies the SAML response using the identity provider’s key, and then redirects the browser to your destination URL.
In the browser, you’re logged in to Oracle Cloud and redirected to the Oracle Cloud service that you logged in to in Step 1.
SAML Identity Provider Requirements
To work with the service provider, which in this case is Oracle Cloud, an identity provider must support SAML 2.0.
Oracle Cloud supports any SAML 2.0–compliant identity provider. The following identity providers have been certified with Oracle Cloud:
Microsoft Active Directory Federation Services 2.0, 2.1, and 3.0
Oracle Identity Federation 11gR1 and Oracle Access Manager and Identity Federation 11gR2
Oracle SaaS applications
User Synchronization Requirements for SSO Configuration
Before configuring SSO, you must ensure that the user population has been synchronized between the identity provider LDAP directory and the service provider directory, with the attribute used to identify the user being the same in both directories for each user.
You can synchronize users manually or import a batch of users into Oracle Cloud from an external directory in the My Services application from the Users tab. To synchronize users manually, create users one at a time. To import a batch of users, create a list of comma-separated values that contain the first name, last name, email address, and login ID for each user.
The attribute used by SAML to identify the user must be the same in both the identity provider LDAP directory and the service provider directory.
If you want to use the email address as that attribute, then each user must have a unique email address. For example, if the LDAP directory is Oracle Internet Directory,
If you want to use the user identifier as that attribute, then each user must have a unique user ID. For example, if the LDAP directory is Oracle Internet Directory,
uidwould be such an attribute.
Automated and Manual Configuration
You can select automated or manual when configuring SSO, and when configuring the service provider and the identity provider.
When you configure the service provider, you can select whether to import identity provider metadata or to enter identity provider metadata manually. Your choice depends on whether your identity provider can export metadata.
Configuring the Service Provider Automatically
- Import the identity provider metadata into Oracle Cloud.
- Complete the SSO Protocol, User Identifier, and contained in fields.
- The user identifier is the Oracle LDAP directory attribute that’s used to map the user information contained in the incoming SSO SAML assertion to an Oracle Cloud user. It’s either the user's email address or the user ID.
- If the user identifier is the user's email address, then the contained in field must show NameID.
- If the user identifier is the user ID, then the contained in field must show SAML Attribute; you must specify the name of the SAML attribute to use.
Configuring the Service Provider Manually
- Provide the issuer ID and the SSO service URL of the service provider.
- Indicate whether the global logout should be enabled.
- Download your identity provider’s signing certificate and encryption certificate.
Configuring the Identity Provider
When you obtain data from the service provider to configure the identity provider, you have two choices, depending on the identity provider’s capabilities:
If your identity provider can import metadata, you can export the metadata from the service provider to import into the identity provider.
If your identity provider can’t import metadata, then you must copy and paste the provider ID and the SAML assertion consumer URL of the Oracle Cloud service into the identity provider configuration. You must also export the service provider signing and encryption certificates into the identity provider configuration.
Testing Your SSO Configuration
The SSO Configuration page lets you configure and test your SSO configuration.
Before you enable SSO, test your SSO configuration. A successful test ensures that your company's users can use their company credentials to log in to all applications, including Oracle Cloud applications.
- Click the Test button. This opens the Initiate Federation SSO page.
- Clicking the button triggers a Federation SSO flow. You’re redirected to the identity provider and challenged for authentication.
- Log in as an administrator. After the Federation SSO is performed, the result is displayed in the Test SSO page. If testing your SSO configuration fails, then troubleshoot the configuration.
Troubleshooting Your SSO Configuration
If testing your SSO configuration was not successful, follow the troubleshooting guidelines.
To troubleshoot your SSO configuration:
Review any changes made on the identity provider and Oracle Cloud before the SSO flow failed.
To capture an HTTP trace of the SSO attempt, use a web debugging and tracing tool such as Fiddler Web Debugging Tool .
To determine the point where the SSO flow terminated and which identity-related components are involved (for example, the identity provider, service provider, web tier, gateways, proxies, and firewalls), review the SSO Test results page.
To identify exceptions, review the SAML protocol messages and component logs.
Go to MyOracle Support to review known problems and find out if your problem has been seen before.
If you have performed troubleshooting Step 1 through Step 5, and you’re confident that the problem is because of Oracle Cloud, contact Oracle. Be ready to provide all your information, including the Fiddler trace, identity provider metadata, and identity provider logs.