Notifications

2160 views

Description

This article describes the steps required to configure your instance so that users can log in via SSO using both the "service-now.com" and custom URL.

If your intention is setup SSO only for the custom URL, please review the notes of each of the steps.

Release or Environment

Custom URL is only supported from London release and onwards.

Cause

After setting up a Custom URL for your instance, users are no longer able to log into the ServiceNow instance using SSO.

Resolution

  1. Navigate to (Custom URL > Custom URLs) and ensure that the Status field is Active for your Custom URL record.

    • Note support.acme.com is used as an example, not as a real domain name




  2. Navigate to (Multi-Provider SSO > Identity Providers) and open up your Identity Provider record.

    • Note : If you intend to only use the Custom URL for SSO, please replace all "service-now.com" values with your custom URL.



  3. Click on Generate Metadata and use this to import or update the associated ServiceNow Instance configuration on your Identity Provider.

    • Note : You will notice that there are AssertionConsumerService entries for both the "service-now.com" and custom URL.

    <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://acme.service-now.com">
       <SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
            <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://acme.service-now.com/navpage.do"/>
            <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
            <AssertionConsumerService isDefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://acme.service-now.com/navpage.do" />
            <AssertionConsumerService isDefault="false" index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://support.acme.com/navpage.do" />
            <AssertionConsumerService isDefault="false" index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://acme.service-now.com/consumer.do" />
            <AssertionConsumerService isDefault="false" index="3" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://support.acme.com/consumer.do" />
       </SPSSODescriptor>
    </EntityDescriptor>













  4. Depending on your Identity Provider, please refer to the relevant sections under Additional Information below.

  5. Once Identity Provider has been configured correctly, please navigate back to the Identity Provider record within ServiceNow and select Test Connection.

    • Note : If you are configuring your instance to only use custom URL for SSO, you will need to be logged into the instance using your custom URL.

  6. Assuming the SSO test completes successfully, select Activate and you are now ready to log into your instance via SSO using your new custom URL.

 

Additional Information

Examples of Application Specific Configurations using both "service-now.com" and Custom URL

  • acme.service-now.com : This refers to your ServiceNow instance URL.
  • support.acme.com : This refers to your Custom URL.
  • <instance_url>/navpage.do : This is the main instance page (if you are unsure, please use "navpage.do").
  • <instance_url>/consumer.do : This is the default endpoint used by ServiceNow's Approval with e-signature plugin.

Microsoft Active Directory Federation Services (ADFS)

After importing the ServiceNow metadata or manually updating the associated ServiceNow Relaying Party Trusts, the Endpoints should look similar to the following.

This configuration should allow you to log into your instance via SSO using both your "service-now.com" and custom URL.

 

Okta - ServiceNow UD Application

The limitation with Okta's ServiceNow UD Application is that it does NOT support multiple SAML Assertion Consumer Endpoints.

In order for this to work, you will need to create two ServiceNow UD Okta Applications:

  • One Okta Application for your "service-now.com" instance URL
  • One Okta Application for your custom URL

 

Okta - Custom SAML 2.0 Application Integration (advanced setup)

  • Note 1 : This is an advanced setup and requires knowledge of SAML 2.0, Okta and ServiceNow platform
  • Note 2 : If you decide to create your own Custom SAML Application, you will lose functionality like User Provisioning (which is provided by ServiceNow UD).

Initiate the creation of a new SAML Integration Application within Okta, which allows the support for multiple SAML Assertion Consumer Endpoints.

Create additional Requestable SSO URLs. At bare minimum you will need to create two entries ("service-now.com" and custom URL) for "navpage.do".

If you are using Approval with e-signature plugin, you will need to create an additional two entries for "consumer.do".

 

Other SSO Appliances

The configuration of other SSO appliances really depends on it's features and functionality.

Does your SSO appliance support multiple SAML Assertion Consumer Endpoints?

  • If the answer is YES, then you can proceed to use the above configurations as guidelines to configure your Identity Provider with both the instance "service-now.com" and custom URL

Does your SSO appliance provide a different SingleSignOnService endpoint for each Identity Provider configuration?
ie. Take Okta for example, each configuration has it's own unique endpoint

  • If the answer is YES, then you will need to configure two configurations (one for the "service-now.com" and another for the custom URL). You will then need to two Identity Provider records within ServiceNow for each of the relevant SSO appliance configuration

If your SSO Appliance does not provide either of the above mentioned features, then unfortunately you may only be able to use either the "service-now.com" or custom URL with SSO.

Article Information

Last Updated:2019-11-24 18:53:50
Published:2019-11-25