Single Sign-On (SSO)

SAML is an XML-based solution that provides a secure solution for exchanging authentication and authorization of user security information between IDPs and the applications like Oracle CPQ.

To see your SAML metadata, enter the following into:

yourbrowser:yourcompanyname.oracle.com/sso/spmetadata.jsp

You need this information to register Oracle CPQ as a service provider within an IDP.

Identity providers are sites or services that provide a security credential (such as an authentication or authorization assertion) on behalf of a user. In some cases this security credential may contain a set of attributes like a user's name or an employee number identifier.

An External ID is often used if a customer's security policy does not allow the username to be sent out of the IDP. Instead, the IDP sends out some other form of identification (employee number, alias, and so on) which has to match the External ID field in the User Object.

An assertion carries authentication and authorization statements, or credentials, about a user that the IDP claims to be true. In this case, this information is sent to Oracle CPQ to be verified against your SSO configuration.

For example, an assertion encodes the following information:

The authentication statement, in particular, asserts the following:

Likewise, the attribute statement asserts that:

Assertion time, also known as a heartbeat, TimeToLive, or NotOnOrAfter, is used by an IDP to check if an IDP session is still active. If you have specified an assertion time on your IDP, Oracle CPQ will use it to check if the IDP session is still active.

Assertion time is independent of the Oracle CPQ session timer (which is set internally by Ops), and elapses regardless of whether the time is spent idle or not.

• If the IDP session is still active, the Oracle CPQ session continues and the assertion timer resets and starts over again.
• If the IDP session is no longer active, the user is automatically redirected to the IDP login page to renew the IDP session. This will, in turn, renew the Oracle CPQ session as well.
• A user cannot bypass an expired assertion time by returning to an Oracle CPQ page. If a user tries to do this, they are redirected back to the IDP login page. If the IDP session is not renewed within two minutes, the IDP logs the user out of the Oracle CPQ session.
• When an IDP assertion check occurs, the user’s Oracle CPQ page refreshes briefly. After asserting the IDP session is still active, the user is taken back to the Oracle CPQ page they were on, but unsaved work will be lost.
• If an IDP assertion check occurs while the user is on a Transaction, and the IDP session has been confirmed as still active, the user is taken to an Access Denied page. From that page, the user has the option to Go Home. The user can then return to the Transaction from the Home Page.

Best practice suggests that the assertion time should be a very long time, usually several hours. The assertion time is set in the IDP.

• Size: Small
• Frequency: Triggered during each login
• Format: SAML 2.0 or SOAP Web Service
• Transmission Synchronization: Synchronous

You can choose to automatically redirect users without an active Oracle CPQ session to the IDP login page, without having to append /sso/saml_request.jsp to the URL. The IDP login page becomes, in effect, the official login page for that Oracle CPQ site. This option is implemented for an entire site.

With this option enabled, if a user manually enters the URL for a specific Oracle CPQ page, they will still be taken to the IDP login page. However, relay logic is put in place so that the user is automatically directed to the desired endpoint (the specific Oracle CPQ page) after login.

Logging out of an Oracle CPQ session will do one of two things:

• If the user no longer has an active IDP session, the user is redirected back to the IDP login page.
• If the user still has an active IDP session, the user is redirected back to Oracle CPQ with a renewed session. To the user, it is as if they have not logged out.

This ensures that the IDP is the session master, not Oracle CPQ. If this is not the desired functionality, specify the SAML Logout URL and SAML Single Logout Endpoint on the Single Sign On Settings page. With this information, logging out of the Oracle CPQ session also logs out of the IDP session.

Automatic IDP redirect is not compatible with guest sessions. If guest sessions are enabled (on the Options-General page), automatic redirect will not work.

Instead of being redirected automatically to the IDP login page, the user will go to the Oracle CPQ login page. Similarly, if automatic IDP redirect is enabled, validation will prevent guest sessions from being enabled.

Automatic IDP redirect is only supported if Single Sign-On Method (on the Single Sign On Settings page) is set to Federated Authentication or Federated and Remote.

This feature is disabled by default. Open a ticket on My Oracle Support to enable this feature.

Setup Tips

There are no settings to observe to determine if Automatic IDP Redirect is turned on; open a ticket on My Oracle Support to see if Automatic IDP Redirect is on or off. Administrators, however, must turn off guest sessions either before or after this feature is enabled.

To determine if automatic IDP redirect is working or even enabled:

• If the feature is enabled and working properly, the automatic redirect will occur.
• If the feature is enabled but the user is taken to the Oracle CPQ login page, there will be an entry in the error logs about why the automatic redirect did not occur. For troubleshooting purposes, there are two main causes for this:
  • SSO is set to None or Web Services
  • Guest Sessions are enabled.
• If the automatic redirect to the IDP does not occur and there is no error entry indicating the cause, then the feature is not enabled on the site.

A signed request is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. This helps establish a level of trust to ensure that, for example, when Oracle CPQ makes a request to an IDP, the IDP can verify that it is actually Oracle CPQ that made the request, and not an attacker disguised as Oracle CPQ.

In the Single Sign On Settings page, an Oracle CPQ admininistrator can now optionally provide a Java SAML Request Keystore file, along with a corresponding Request Keystore StorePass and Request Keystore KeyPass, so that SAML requests to the IDP are signed.

For more information on SAML standards, see the Notes section below.

Each user that needs to access the Oracle CPQ application through SSO must have an Oracle CPQ user account.

Users must exist in CPQ, but SSO can be configured without a password if you are using Federated Authentication. When using Remote WebServices, Oracle CPQ will still require a password.

1. Navigate to the Admin Home Page.
2. Click Internal Users in the Users section.
3. Click a Login.

4. Select an option from the Enable for SSO drop-down.

   If the User is enabled for Single Sign-On login, then when the site itself is enabled for SSO, the user can log in with SSO. If you know the user's External SSO ID, then that can be used for SSO. Otherwise, the User's Login will be used. There are three options to choose from:

   • Not Enabled: SSO is not available for this user; they must log in to Oracle CPQ directly.
   • Enabled for SSO: SSO is available for this user; they can log in to Oracle CPQ directly or through SSO.

   • SSO Only: SSO is available for this user; however, they cannot log in to Oracle CPQ directly.

     

1. Navigate to the Admin Home Page.

2. Click Single Sign-On under Integration Platform.

   

3. Select Federated Authentication from the Single Sign On Method drop-down.
4. For Oracle CPQ Issuer URL, enter https://yoursitename.oracle

5. Click Choose File to locate and upload an Identity Provider Certificate.

   This file details how to communicate with each particular Identity Provider. For example, information such as the IP login and logout, and NameID formats, are in this file.

6. If necessary, enter a SAML Requested Name Identifier Format.

   Each IDP supports different NameID formats, which can be found in the IDP configuration. FullAccess users can customize this field. If the field is left blank, the setting defaults to using the "transient" format.

   Common NameID Formats:

   • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

   • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

   • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

   • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

7. Enter the SAML Identity Provider URL.

   This is a required step because all assertions that are sent to Oracle CPQ need to have an Issuer value that is identical to this field.

8. Enter the SAML Logout URL.

   Whenever an Oracle CPQ user is logged out (via a session timeout, or by the user manually logging out), the user will be redirected to the SAML Logout URL. If a SAML Logout URL is not defined, the user will land on the Oracle CPQ login screen after being logged out.

   In some implementations, you may wish to only show the login screen of the IDP and never show the Oracle CPQ login screen. In this scenario, set the SAML Logout URL to the URL of the IDP login screen.

9. Enter the SAML Single Logout Endpoint.

   The SAML Single Logout Endpoint may be the API Endpoint URL of the logout Web Service of the partner system. In this scenario, whenever an Oracle CPQ user is logged out (via a session timeout, or by the user manually logging out), Oracle CPQ will send a Web Service call to the SAML Single Logout Endpoint to trigger the logout of the user in the partner system.

   Adding a valid SAML Single Logout Endpoint essentially creates a “global logout” scenario, where whenever a user is logged out of CPQ, they will also be logged out of the partner system. Defining a valid SAML Single Logout Endpoint is a best practice of SSO integrations.

   If the SAML Logout URL or SAML Single Logout Endpoint has a destination that ends the SSO session, other applications may lose data.

10. Select the SAML User ID Type.This specifies which of two identifiers an assertion contains when being sent to CPQ:

    • User's Oracle CPQ username
    • External ID from the User Object

11. Select the SAML User ID Location. This specifies in which of two locations in the assertion a user will be identified.

    • Subject Statement: User ID is located in the <Subject> statement of the assertion.

    • Attribute Element: User ID is located in an <AttributeValue>, located in the <Attribute> of the assertion.

      If this option is selected, the Attribute Name field appears. Enter the value that contains the User ID.

12. Click one of the following options:
    • Apply to save your changes.
    • Update to save your changes and return to the Admin Home Page.
    • Back to return to the Admin Home Page without saving your changes.

https://sitename.oracle.com/?sessionId=SESSION_ID&username=USER_LOGIN&sso=true

Verify:

• Oracle CPQ is configured with the Remote WebServices SSO method.
• From the Admin Home Page, choose Single Sign-On in the Integration Platform section.
• A Oracle CPQ user is enabled for SSO in Oracle CPQ and has an account in their IDP.
• From the Admin Home Page, choose Internal Users under Users. Then click a user's Login.
• The login SOAP API contains an sso tag, for example: <bm:sso>1</bm:sso>.

Once the OAuth Provider with OpenID Connect Integration is setup, complete the following steps to enable OpenID Connect for Single Sign-On.

1. Click Single Sign-On in the Integration Platform section of the Oracle CPQ Home page. The Single Sign-On Settings page displays.

2. Select OpenID Connect from the Single Sign-On Method drop-down.

3. Click Apply. The OAuth Provider with OpenID Connect Integration is connected with the Single Sign-On settings.

4. (Optional) Log a Service Request (SR) with My Oracle Support to include the site domains in the iframe domain allowlist. This step is only required if you are embedding Oracle CPQ in another application that is not already registered in the allowlist.