Define Single Sign-on Configuration Settings

The configuration settings described in this procedure support the implementation of open login.

1. Click Configuration on the navigation pane.
2. Expand Site Configuration, then double-click Configuration Settings.
   The Search window opens.
3. Perform these actions on the Search criteria at the top of the content pane.
   1. Click the Configuration Base menu and select the All check box.
   2. Click the Folders menu, clear the Select All check box in the Folders menu and then select the Common check box.
   3. Click Search.
   The Configuration Settings editor opens with the Common folder displayed on the content pane.
4. Expand the folders in the Common/General/Single Sign-On path to display the SAML_20_SIGN_CERTS and USE_KNOWN_ROOT_CAS configuration settings.
5. Click in the Value column to edit the configuration setting values. See Edit a Configuration Setting.

   Common Single Sign-On Configuration Settings

   Configuration Setting	Description
   SAML_20_SIGN_CERTS	Identifies the only certificate(s) (a comma-separated list of SHA-1 hex thumbprints) accepted for SAML 2.0 signatures for agent or contact IdP-initiated SSO. You can use the value ANY-TRUSTED to accept any certificate that's trusted by the root CAs for the site. Default is blank. Tip: If ANY-TRUSTED is used, we recommend that the USE_KNOWN_ROOT_CAS configuration setting be disabled for security reasons. During IdP-initiated SSO, for either agents or contacts, only certificates listed in the SAML_20_SIGN_CERTS configuration setting are accepted for SAML 2.0 assertion signing for IdP-initiated SSO. This means that if no certificates are listed in the setting—which is its default—then no certificate will be accepted for SAML signing of IdP-initiated single sign-on requests. Listed certificates must still pass other validation criteria (that is, they must be trusted) before they can be accepted for SAML 2.0 assertion signing. 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. See Certificate Validation Options. You can also prefix the list of certificate thumbprints with CERT_VALIDATION:IGNORE_TRUST. This indicates that the certificate used to sign the token (matching one of the certificate thumbprints in the list) doesn't need to be signed by a trusted root CA from the certificate store (i.e. the certificate signature chain's root CA doesn't need to be in the list of well-known CAs, assuming USE_KNOWN_ROOT_CAS is set or added to the Additional Root Certificates store). See Add or Remove Certification Authorities. For example, when a value of CERT_VALIDATION:IGNORE_TRUST,06767A1E3D41A358A8BCA912F36C0E3C5425CD4F,B7C5D22D2AEE2E151ED6D16DA3D6F4EEC7D08676 is entered, two certificates will be accepted for SAML token signatures (with the SHA-1 thumbprints given), but neither will be validated to have been signed by a trusted root CA.
   USE_KNOWN_ROOT_CAS	Controls whether the known root certificate authorities list that's embedded within the Oracle server is consulted when verifying X509 certificates, for example, when checking S/MIME email or SAML 2.0 signatures. Default is enabled (Yes).

6. Click Save.
7. From the search criteria fields on the top of the editor, click the Folders drop-down list, clear the Common check box, and then select the RightNow Common check box.
8. Click Search.
   The RightNow Common folder displays on the content pane.
9. Expand the folders in the RightNow Common/Single Sign-On/General path to display the SAML_ERROR_URL, SSO_ENTITY_ID, and SSO_SAME_SITE_ATTR configuration settings.
10. Click in the Value column to edit the configuration setting values.

    RightNow Common Single Sign-On Configuration Settings

    Configuration Setting	Description
    SAML_ERROR_URL	You can use this setting to specify the URL where users will be sent if their SAML SSO log-in attempt fails. The setting supports the %error_code% and %session% placeholder variables, which are replaced with the error code the user encountered and the session of the user if the user has cookies disabled. The default value for the setting is blank. These errors can be returned when using the %error_code% variable. SAML_TOKEN_REQUIRED—No SAMLResponse POST value was sent to the CP controller. A SAML response is required in order to start the authentication process. The error ID is 14. SAML_TOKEN_FORMAT_INVALID—The SAML response was found, but it could not be successfully Base 64 decoded. The error ID is 15. FEDERATED_LOGIN_FAILED—The call to the federated_login API call failed. This usually means that the SAML assertion succeeded, but the user does not yet exist in the database. The error ID is 16. SSO_CONTACT_TOKEN_VALIDATE_FAILED—The call to the sso_contact_token_validate API failed. This can happen in a number of ways, but the most common is that the SAML assertion contains something other than the contact login as the subject. If that login does not exist in the database, the token validation will fail. The error ID is 17. CONTACT_DISABLED_ERROR—The SAML assertion/login succeeded, but the contact is disabled in the database. The error ID is 6. COOKIES_REQUIRED_ERROR—The user does not have cookies enabled. Cookies are required in order to log in to CP. The error ID is 3.
    SSO_ENTITY_ID	You can use this setting to override the default entity identifier of your B2C Service site. Use this only when the external application doesn't support characters in the default identifier.
    SSO_SAME_SITE_ATTR	An optional site-level parameter that controls whether SSO will be supported to access embedded frames within the Agent Browser UI. Set the value to None to allow SSO access. Leave the value blank if your site doesn't use SSO, or if you don't want it extended to use embedded frames. The default value for the setting is blank.

11. Click Save.