SAML SSO with a Custom URL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-04-2018 04:20 PM
We have a custom URL for our ServiceNow instance, and I would like to have SSO logins work. SSO is already working on our regular / base ServiceNow URL. Please see the scenario I'm facing below. Please note: I'm not using our real URLs below, but I'll use examples that are basically the same as our environment.
A URL like this: https://service.myfakecompany.com (this isn't a real URL)
Serves up our instance to users: https://ourinstance.service-now.com (also not real)
End users never know the ServiceNow URL - the browser always shows the first URL (our custom URL). Of course you can use either URL, but we want all of our users to use the custom URL.
I didn't set up the custom URL - that was done years ago. I assume we're using this method, but I'm not positive
https://community.servicenow.com/community?id=community_blog&sys_id=033e22addbd0dbc01dcaf3231f9619d9
We have an A record in our company's DNS that points to an IP address. I believe this server is rewriting the URL to our ServiceNow instance URL. I'm trying to track down whoever manages this server so I can confirm exactly how its configured and be able to make updates to it if necessary.
We are now implementing SSO using the Multiple Provider SSO plugin. (This Microsoft link describes the method we're using)
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-servicenow-tutorial#configure-azure-ad-single-sign-on-for-servicenow
With the above method, SSO works perfectly with https://ourinstance.service-now.com.
However, when I try from https://service.myfakecompany.com, it does not work. When I attempt an SSO login, this is what happens:
1) Browser briefly flashes error message: Could not validate SAML Response
2) Browser reloads with this text
Logout succeeded
Logout successful
You have successfully logged out.
I need to know how to modify my configuration in ServiceNow or Azure (or both) to make this work from our custom URL. I may also need to modify whatever is happening on the server handling the re-writes, mentioned above. I accept the possibility that this may not work on both URLs… I'm happy if it just works from our custom URL and not the ServiceNow URL.
This is not a technical area that I know much about. I'm aware there are tools like Fiddler that can help me diagnose what is going on, but I don't know how to use them. I'm out of my depth! Thanks in advance for any help.
- Labels:
-
Instance Configuration
-
Integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2018 01:28 PM
Found the solution!
In Microsoft Azure ServiceNow SSO App:
Make these updates to Single Sign-on configuration:
Sign on URL > https://service.myfakecompany.com/navpage.do
Identifier (Entity ID) > https://service.myfakecompany.com
(Advanced Settings > Reply URL > https://service.myfakecompany.com
In ServiceNow (HCCPRD):
Make these changes to update Identity Provider Record
ServiceNow Homepage > https://service.myfakecompany.com/navpage.do
Entity ID / Issuer > https://service.myfakecompany.com
Audience URI > https://service.myfakecompany.com
After updating, SSO will no longer work from ourinstance.service-now.com, but it will work from service.myfakecompany.com
Workaround required to update IDP record in ServiceNow, as the "test connection" was failing (invalid SAML response). I believe this is because ServiceNow is not saving the new values before executing the test. Here's the workaround:
1) Inactivate the IDP record from the list view
2) Make changes in the record and save (3 updates above)
3) Make the IDP record active again from the list view
There is still a remaining issue. We would like to have SSO work with both URLs, but it is not allowed to have two IDP records with the same IDP URL. When we attempt to save the second IDP record with an identical Identity Provider URL value, we get this error:
java.sql.BatchUpdateException: Duplicate entry 'https://sts.windows.net/(YourAzureObjectId)/' for key 'idp'
Error Message Invalid update

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-08-2021 08:39 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-23-2018 08:44 AM
@cphanson- Can you share your experience of setting up the custom URL for your instance. What all changes need to be done to set up a custom URL and are there any limitations.
Thanks
Manisha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2019 10:46 PM
We had to do something similar but with two custom URLs and the base ServiceNow URL. After a lot of digging around, managed to find the attached KB article which is not even available in HI - had to get our account manager to retrieve it. The good news is that it works and allows us to support all 3 URLs via SSO and just the one IDP record so we can enable auto-redirect. Hope you find it useful.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2019 01:16 PM
THANK YOU!!! Good hell, why isn't that info on ANY of the documentation pages touting the ServiceNow custom URL functionality. Seems like this would impact a significant number of customers using Okta as their iDP. I'll make sure to leave feedback on the docs site to see if we can't get this added.
The good news: https://hi.service-now.com/kb_view.do?sysparm_article=KB0725735 is now available to be viewed by logged in users.
The limitation with Okta's ServiceNow UD Application is that it does NOT support multiple SAML Assertion Consumer Endpoints.
Workaround: create two ServiceNow UD Okta Applications, or create a Custom SAML Application and lose functionality like User Provisioning