Multi provider SSO - Access via base URL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-30-2016 06:58 AM
Hi,
Ive recently installed the Multi provider SSO plugin on Eureka. Previously had the SAML 2.0 setup working and have managed to get the new multi working between me and the Identity provider admin.
When applying this to live I want to make it seamless from an end user point of view. Currently in live (using old SAML 2.0 single the end user enters the base url (http://xxx.service-now.com) and gets logged in via the SSO. Having read the following wiki article is this still possible to achieve? I want to avoid having to give the end users (30k +) a newly created URL (as per below article extract).
Is it possible to make a seamless switch over? If so..any advice or direction would be appreciated.
:
Multiple Provider Single Sign-On - ServiceNow Wiki
--------------------------------------------------------------------
5 Logging In
The recommended and most efficient method for users to log in using multi-provider SSO is to use a specifically configured URL. After multi-provider SSO is configured, you can send a URL to your users with the correct IdP in the parameter string. For example:
- /login_with_sso.do?glide_sso_id=<sys_id of the sso configuration>
After a user successfully logs in to the IdP page, a cookie containing the IdP sys_id is added to the browser. The next time the user attempts to log in to the ServiceNow system, the system redirects the user to log in to the IdP server, which automatically logs in to the ServiceNow system.
If a URL parameter is not set or the browser cache has been cleared, users can also do the following:
- Click the Use external login link on the ServiceNow login page.
- The external login page appears. Users can click Use local login to return to the standard ServiceNow login page.
- Enter the value for the specified field on the user table that you configured in Multi-Provider SSO properties.
- The user is redirected to the IdP server, where they log in.
- Labels:
-
Integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-31-2016 04:22 AM
To mention..we are using Eureka and so does not have the option for 'primary' idp.
Found the below on the wiki which is exactly what I want, but I want to do this prior to upgrade from Eureaka..any thoughts?:
12.1 Fuji
- Provides a property to identify a primary identity provider. The primary IdP is used automatically for all users if they try to access the base URL of the instance.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-31-2016 01:04 PM
You could always create an installation exit override to the redirect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-24-2016 10:17 AM
Russell,
Did you hear back from support? I just upgraded and I have the same issue - users are not being authenticated automatically and if I show them the side_door page and ask them to use the external login link they are asked for their userid and they are logged in. I configured the glide.authenticate.sso.redirect.idp property but this is not redirecting users to the right place automatically.
Cheers!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2016 12:36 AM
Hi,
To be honest..I decided to stick with the SAML 2.0 and ditched the multi for now..as was on Eureka and at this stage only needed one IDP. Planning to go to Helsinki..so once upgraded will add the multi provider plugin back in and set up a primary.
When creating and populating the property: glide.authenticate.sso.redirect.idp did you try prefixing the provider sys_id with "sso:"?..never tried that...i dont think
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2016 08:22 AM
I just had to tweak the glide.authenticate.sso.redirect.idp property, here you put the SysID of the idp - in my case it had a different value from the migrated one.
I also ensured that the 'migrated idp' was set to active and was my default and I disabled all other ones (why have something active when you don't know what it does)...
What I found is that people who tried connecting before I configured SSO were not automatically authenticated and were instead dumped on the logout screen. Once I had them clear their cookies the login behavior was as expected. Anyone who tried connecting after I configured it worked fine. I found that the best way to test this is to run an inPrivate / Private / Incognito window.