ServiceNow: Configure Multi-SSO IDP against Multiple Azure Active Directories

Author by Michael Dugan

ServiceNow offers Single Sign-On plugin functionality for your organization to leverage a different authority for authenticating into the platform. Most organizations typically find that they only have one identity provider to authenticate against, but a recent customer of ours is a service provider that manages multiple identity providers for their customers. Note that this blog post will focus on Azure Active Directory specifically.

Microsoft’s ServiceNow SSO Walkthrough Document

The guide that you will want to use to drive the Azure setup of this functionality is located at this location: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/servicenow-tutorial

This process must be followed for every Azure tenant within the organization so that the ServiceNow instance can properly communicate with Azure via signed certificates. This will set up the ServiceNow instance with specific URLs for authenticating against the specific domain.

ServiceNow Multi-SSO Configuration

With the enterprise application enabled and URL captured for authentication, follow these steps in ServiceNow:

  • Activate the “Integration - Multiple Provider Single Sign-On Installer” plugin to load the core functionality (ID: com.snc.integration.sso.multi.installer)

sso1-(1).png

  • Follow the following guide from ServiceNow to ensure that your instance is properly configured for system settings:
    1. https://docs.servicenow.com/bundle/newyork-platform-administration/page/integrate/single-sign-on/task/t_SettingUpMultiProviderSSO.html
  • Be sure to test the connection to the identity provider and ensure that it works. Repeat this process for every identity provider that needs to be configured in ServiceNow
  • Create a business rule that will make sure the user’s company sso value is set on the user record.
    • Name: Update User SSO Settings
    • Table: User [sys_user]
    • Check the advanced checkbox
    • When: before
    • Check the Insert and Update checkboxes
    • Filter conditions: Company is not empty or Company changes
    • Script (click save/update once code is filled in:
if (current.sso_source != current.company.sso_source)
{
      current.sso_source = current.company.sso_source;
}
  • This code checks the user’s company record sso_source value and updates the user record sso_source value with it if it’s different. If it’s the same value, nothing will happen.
  • Head over to User Administration > Companies and manually create the company records needed for the SSO integration. Make sure that the company name matches exactly what is in Azure Active Directory for your users. The user record in ServiceNow will have a related company as part of the user provisioning process if the name is correct. If this is not happening, revisit the company records and check the name field to ensure the spelling matches the company in Azure Active Directory.
  • Update the “sso_source” field on the company records to have the identity provider sys_id that they will authenticate against. It must be formatted in the following manner: sso: SYS_ID

sso2.png

  • Head over to Multi-Provider SSO > Identity Providers in ServiceNow and make sure that EVERY identity provider record is set to false for default
    • This means that every identity provider ServiceNow knows about will not take the user to a specific URL every time, as we need to let it come down to the user’s company record and the configured SSO identity provider from the previous step

ServiceNow User Provisioning

With the previous steps completed, this guide assumes that users will be provisioned in ServiceNow through Azure Active Directory. When setting up the fields to be brought over to the ServiceNow instance from Azure Active Directory, be sure to bring over the user’s company. This is a data requirement for this ServiceNow SSO redirection guide.

Test the Configuration

When these steps are complete, test the Multi-SSO use case by using the “Use external login” link on the login page of the instance (navpage.do). Use a user that has a specific SSO source value that belongs to a different directory and test that they are directed to the appropriate IDP when using the external login link.

If you can login successfully via SSO, this will complete the setup and enable your organization to leverage multiple identity providers for the user to authenticate against!

Closing Thoughts

There are some system properties that allow for additional external login customization. If you are experiencing any issues, reference ServiceNow’s documentation around authentication properties:

Author

Michael Dugan

Systems Engineer

Tags in this Article