You can create or update a SAML 2.0 SSO configuration from the Multi-Provider SSO feature.

Before you begin

Role required: admin

About this task

Note: New to the Jakarta release, you must validate your configuration by using the Test Connection functionality before you can activate your IdP configuration. You can still use the Update functionality to save your configuration data, but it is not an active configuration without a successful test connection.

Procedure

  1. Navigate to All > Multi-Provider SSO > Identity Providers.
  2. Do one of the following options.
    • To update a configuration, click an SSO configuration record.
    • To create a new configuration, click New > SAML.
  3. For a new configuration, enter the IdP information by one of the following methods:
    OptionDescription
    Using a metadata descriptor URL Click the URL check box and enter the URL of the IdP that you are using.
    Using metadata descriptor XML file Click the XML check box and paste in the XML data generated from the IdP you are using.
    Entering metadata manually Close the popup window and manually enter the data in the property fields.
    All required fields must be filled-in on the Identity Provider form. IdP form
    Table 1. Multi-provider single sign-on fields
    PropertyRequiredDescription
    Name Yes Enter the name for the IdP. This IdP is the auto redirect sys id.
    Active Yes Active should be set to true for the IdP to be used for authentication.
    Note: The option to set this property only comes after a successful test connection.
    Default No The Auto Redirect IdP, formerly known as the Primary IdP, automatically redirects users to access the base instance URL. This property sets this IdP configuration as the default.
    Auto Redirect IdP No Sets this IdP configuration as the Auto Redirect IdP.
    Note: If you make a new Auto Redirect IdP configuration active, the glide_sso_id cookie updates with the new Auto Redirect IdP. The glide.authenticate.sso.update.idp.cookie system property, automatically enabled, controls this feature.
    Identity Provider URL Yes Enter the URL to your IdP. Each IdP URL must be unique.
    Identity Provider's AuthnRequest Yes Enter the URL to the HTTP-Redirect binding obtained from the SingleSignOnService element.
    Identity Provider's SingleLogoutRequest No Enter the URL obtained from the SingleLogoutService element.
    ServiceNow Homepage Yes Enter the URL, including login page, of the instance for which the IdP authenticates. For example: https://yourinstance.service-now.com/navpage.do
    Entity ID/Issuer Yes Enter the base URL, excluding login page. of the instance for which the IdP authenticates. For example: https://yourinstance.service-now.com/
    Audience URI Yes Enter the base URL, excluding login page. of the instance for which the IdP authenticates. For example: https://yourinstance.service-now.com/
    NameID Policy Yes Enter the value of the NameIDFormat element the integration uses.
    External logout redirect No Enter the URL where the integration redirects users after they log out.
    Failed Requirement Redirect No Enter the URL for redirecting failed authentication requests. By default, this is the URL endpoint of an error page or logout page configured in the IdP. You can populate this value in the glide.authenticate.failed_requirement_redirect field.
  4. (Optional) Encryption And Signing tab
    Note:
    • It is recommended to use your own certificates for the encryption and signing.
    • The FIPS approved mode requires different certificates for Encryption and Signing
    • While using the certificates, make sure to update the following system properties with the sys_id of the certificates (x.509 Certificates):
      • Signing (glide.authenticate.sso.saml2.keystore)
      • Encryption (glide.authenticate.sso.saml2.encryption.keystore)
    • Make sure to update the key alias and key password of the Signing and Encryption keystores in the Identity Provider record and generate the metadata (Select Generate Metadata).
    • Upload the signing and encryption certificates present in the generated metadata (XML) to the Identity Provider.
    Encryption And Signing
    Table 2. Encryption And Signing fields
    PropertyDescription
    Signing Key Alias Enter the Signing alias of the key entry stored in SAML 2.0 SP Keystore.
    Signing Key Password Enter the Signing password of the key entry stored in SAML 2.0 SP Keystore.
    Encryption Key Alias Enter the Encryption alias of the key entry stored in SAML 2.0 SP Keystore.
    Encryption Key Password Enter the Encryption password of the key entry stored in SAML 2.0 SP Keystore.
    Encrypt Assertion Select the check box to encrypt the assertion in the SAML response. The metadata generated for the IDP embeds the x509 certificate, which the IDP uses to encrypt the assertion in the SAML response that it generates.
    Signing Signature Algorithm Enter the URL that points to the SAML 2.0 Identity Provider AuthnRequest Consumer for eSignature Authentication.
    Sign AuthnRequest Select the check box to enable the IdP single-sign on service to receive a signed AuthnRequest.
    Sign LogoutRequest Select the check box to enable the IdP single-sign on service to receive a signed LogoutRequest.
    Sign Logout Response Select the check box to enable the IdP single-sign on service to receive a signed Logout Response.
  5. (Optional) User Provisioning tab
    User Provisioning Tab
    Table 3. User Provisioning fields
    Property Description
    Auto Provisioning User Enable automatic user provisioning, creates the users when user doesn't exists in the instance User Table based on the information provided by the IdP.
    Update User Record Upon Each Login Updates user information in the instance User table with the information in the IdP each time the user logs in using SAML.
  6. (Optional) Advanced tab
    Advanced tab
    Table 4. Advanced fields
    PropertyDescription
    User Field Enter the field on the User table that contains the value the IdP requires to identify the user. This is a unique id as part of the response. For example, user name, employee id, and so on. In the sys user table, this unique id is matched with the user details.
    NameID Attribute Leave this field blank unless you configure a new NameID policy. If you configure a new policy, the system requires the User table it must use to identify the user logging in. The system matches the NameID token to the name of that User table field here.
    Create AuthnContextClass Select the check box to specify a particular context class such as Password Protected Transport. If the check box is cleared, the IdP selects the most appropriate context class.
    AuthnContextClassRef Method Enter the URN of the login mechanism you want the IdP to use to authenticate users.
    Force AuthnRequest Select the check box to force AuthnRequests to occur.
    Is Passive AuthnRequest Select the check box if the AuthnRequest is passive.
    Single Sign-On Script Select the Single Sign-On script. The default is MultiSSOV2_SAML2_custom.
    Sign Logout Response Enter the logout response details in this field.
    Clock Skew Enter the number of seconds between the two attributes that make up the SAMLResponse nonce. The default is 60. A valid SAMLResponse must fall between the notBefore and notOnOrAfter date-time values. See Sample SAML 2 Response with the SubjectConfirmation and SubjectConfirmationData Elements and Sample SAML 2 Response with the AudienceRestrictions and Audience Elements for a sample SAMLResponse message.
    Protocol Binding for the IDP's SingleLogoutReuqest Enter one of the supported values listed in the Binding attribute from the SingleLogoutService element.
    Metadata URL from which IDP properties are imported The IdP properties import from this URL. If set, it enables the automatic import of SAML certificate from the IdP if the previous certificate has expired.
    Note: If you upgrade from SAML2 Update 1 to Multi-Provider SSO or if you manually set up your SSO connection, the IdP Metadata URL does not automatically populate.
    Request An unique id as part of request, the id can be user name, employee id, and so on.
    Note: Both redirect and post binding is supported for request. The option to set this field only appears after a successful test connection. For more information see, Testing IdP connections.
    Response An unique id as part of response, the id can be user name, employee id, and so on.
    Note: Both redirect and post binding is supported for response. The option to set this field only appears after a successful test connection. For more information see, Testing IdP connections.