RightNow CX includes single sign-on (SSO) support for agents working on the RightNow CX Console and customers using the customer portal. Instead of logging in with their RightNow CX user name and password, agents and customers log in to a third-party identity provider, which authenticates their identity.

Then they select a connection to the application, either the RightNow CX Console for agents or the customer portal for customers. The identity provider first verifies their login. It then encapsulates the result of that verification in an assertion that is signed using an X509 certificate and sends the assertion to RightNow CX.

The application verifies the signature and (if successful) accepts the account information for logging in to the RightNow CX system. The assertion sent by the identity provider uses SAML 2.0 (Security Assertion Markup Language) architecture.

Note: This implementation of SAML 2.0 open login lets RightNow CX accept identity provider assertions, but not initiate them. Single logout is not supported.

Single Sign-On Process Overview:

Customer login

The following process occurs when single sign-on is enabled for customers logging in to the customer portal.

1. A customer enters a user name and password to log in to an identity provider. When the identity provider verifies the information, the customer is logged in.
2. The identity provider displays a list of service providers, including the customer portal, that the customer can connect to.
3. The customer selects the customer portal.
4. The identity provider generates a signed SAML 2.0 assertion using the contact’s email address, contact record ID, login name, or a contact custom field as the assertion subject.
5. The identity provider then submits the assertion, using HTTP POST binding (since that is the only binding method RightNow CX supports), to the customer portal openlogin controller at http://<your_site&gt;.custhelp.com/ci/openlogin/saml/. This controller calls the SSO validation and logs in contacts.
6. RightNow CX decodes the assertion, validates the customer by confirming that the assertion matches a contact record in the RightNow CX database, and logs the customer in on the customer portal’s Support Home page. (A redirect parameter can specify that a different page opens instead).

Note: Contact records cannot be created through the SSO process, so only existing customers can be logged in (The public API can be used to create or update contacts if necessary).

Note: The assertion must be signed using W3C XML signature recommendations. If the certificate used to sign the assertion is self-signed, it must be uploaded to the Additional Root Certificates (certs/root/) directory in the File Manager. The certificate must also be listed in the SAML_20_SIGN_CERTS configuration setting or it will not be accepted for SAML signing. Additionally, the assertion cannot be encrypted.

Setting up single sign-on

Complete the following steps to configure single sign-on for your site.

• Contact Oracle RightNow account manager to enable SSO for agents or customers or both
• Enable single sign-on profile permission (for Agents).
• Define configuration settings.
• Set up one or more identity providers.

Defining configuration settings

1. Click the Configuration button on the navigation pane.

2. Double-click Configuration Settings under Site Configuration. The content pane displays the Configuration Editor

3. Edit SAML_20_SIGN_CERTS and USE_KNOWN_ROOT_CAS (on Common > General > Single Sign-On) according to the following descriptions (click the Update button after editing the value for each setting).

• SAML_20_SIGN_CERTS: Identifies the only certificates that are accepted for SAML 2.0 signatures. The special value of “ANY-TRUSTED” may be used to accept any certificate that is trusted by the root CAs for the site. If the “ANY-TRUSTED” setting is used it is highly recommended that the USE_KNOWN_ROOT_CAS setting be disabled for security reasons. Default is blank.
• USE_KNOWN_ROOT_CAS: Controls whether the known root certificate authorities list that is embedded within the Oracle RightNow server is consulted when verifying X509 certificates. For example, when checking S/MIME email or SAML 2.0 signatures. Default is enabled (Yes).

4. Click the Commit and Exit button

5. Edit SAML_ERROR_URL (on Common > Single Sign-On > General) according to the following description

• SAML_ERROR_URL: Specifies the URL that users will be sent to when their SAML SSO log-in attempt fails. This setting supports %error_code% and %session% placeholder variables. These will be replaced with the error code the user encountered and the session of the user if the user has cookies disabled. Default is blank.

6. Click the Update button, and then click the Commit and Exit button.

Setting up identity providers

In order for RightNow CX to accept SAML 2.0 open login assertions from third-party identity providers, each identity provider needs to be configured to send the assertion URL to the RightNow CX application, either to the SSO launch page for agent login or to the customer portal openlogin provider for customer login (or to both).

RightNow CX can accept authentications from multiple identity providers. Configuration details vary from provider to provider, so each one must be configured separately to make the application available through the identity provider. The following list includes some requirements and constraints you must consider as you configure an identity provider

• RightNow CX does not support the import of SAML 2.0 metadata.
• RightNow CX supports single sign-on only when it is initiated by the identity provider. It does not support RightNow CX-initiated sign-on, nor does it support single logout.
• RightNow CX does not support decryption of the SAML 2.0 assertion, so the identity provider should not be set up to encrypt the assertion. Instead, use an SSL connection for confidentiality.
• RightNow CX supports only the HTTP POST binding type, so the identity provider should be configured to send SAML responses and assertions using that method.
• The certificate used to sign the assertion must be included as part of the assertion in the XML signature.
• The identity provider server is expected to be time-synchronized with the Oracle RightNow server, so a validity range of plus or minus five minutes of the SAML assertion should be adequate.

Identifying the SAML subject for contact login

The parameter used to identify the SAML subject contents should be passed to the customer portal openlogin controller as a GET parameter. The format of the URL is:

/ci/openlogin/saml/subject/{SAML_subject}

For example: /ci/openlogin/saml/subject/contact.emails.address

The subject value must be unique in order for the single sign-on to be successful. The parameter, named subject, is optional and defaults to contact.login. Its values include the following:

• contact.emails.address – The assertion subject is the contact email address, and the value can be the contact’s primary email address or one of the alternate email addresses. The contact.emails.address value is case insensitive.
• contact.id – The assertion subject is the contact ID in the Oracle RightNow database.
• contact.login – The assertion subject is the contact login, which is the preferred mapping since it requires no lookup from the database. This is the default mapping value if subject is not set. The contact.login value is case sensitive.
• contact.customfields.[customfield-name] – The “customfield-name” variable is the actual name of the custom field in the database (as well as the name of the database column), and the assertion subject is the contact custom field value. The assertion subject is then passed to the API as CustomField and the name in the subject GET parameter is sent to the API as the CustomFieldName value. The c$ prefix will be added if necessary.

Note: The custom field value is case insensitive. The following contact custom field data types are not supported for use in an assertion.

• Menu
• Yes/No
• Date/Time
• Date Field
• Opt-in

Redirecting after login

After the assertion has been verified and customers are identified and logged in, they will be directed to the customer portal Support Home page by default. If you prefer to direct them to another page, you can add a redirect parameter to the URL that passes the subject parameter. The redirect parameter can point to any customer portal page (/app/*) or controller endpoint (/ci/* or /cc/*). It must follow the subject parameter, as shown in the following example URL.

/ci/openlogin/saml/subject/contact.id/redirect/app/ask

Important note: To know more about SAML 2.0 click this link