How to setup SSO for Custom URL - Support and Troubleshooting

How to setup SSO for Custom URL Issue 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 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 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

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.

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. https://acme.service-now.com "> https://acme.service-now.com/navpage.do "/> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress https://acme.service-now.com/navpage.do " /> https://support.acme.com/navpage.do " /> https://acme.service-now.com/consumer.do " /> https://support.acme.com/consumer.do " />

Depending on your Identity Provider, please refer to the relevant sections under Additional Information below. 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. 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. Note: After setting the custom URL and if it is the only active record in IDP Providers and if you are trying to access original service-now url then you have to uncheck the auto-redirect URL flag on the custom url IDP record.

This KB was prepared just for browser in mind, albeit it should work for mobile apps too but you might have to look at other mobile app related configurations as well.

Related Links 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. /navpage.do : This is the main instance page (if you are unsure, please use "navpage.do"). /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 Also please note the following:

Note 1 : In order for "Test Connection" to run successfully, you will need to ensure that Disable Force Authentication is UNCHECKED within your Okta configuration. https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-ServiceNow.html#force Note 2 : When running "Test Connection" from the Identity Provider record, please ensure you are logged into the instance based on the base URL, if testing the Identity Provider record associated with the base URL; or if testing the Identity Provider associated with the Custom URL ensure you've logged in via the Custom URL (e.g customurl.example.com) 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".

SSO using OIDC Keycloak

A customer using the open-source IdP Keycloak on-premise and in OIDC mode wanted to use two separate Custom URLs pointing to different Service Portals for two separate user groups, as well as use OIDC login on the base URL for a third user group. They were able to successfully get this working by setting up 3 different OIDC Identity Provider[oidc_identity_provider] records on the instance (Multi-Provider SSO->Identity Providers).

Two of the OIDC Identity Provider records had ServceNow Homepage set to the respective Custom URL, with the third set to base URL (with /navpage.do ). The OIDC Entity Profile is separate for each, as they are seen as separate configurations on the IdP (Keycloak) side as well. The base URL OIDC Identity Provider[oidc_identity_provider] was set as 'Auto Redirect IdP', and users reached the two Custom URLs via clickinglinks in an intranet portal page on the customer's network which use "/login_with_sso.do" (e.g "Login to Example Group Portal" with href= https://my.customurl.example.com/login_with_sso.do?glide_sso_id=ac2356e01bcb952022659274bc4bcb5a ).

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.