Applicable Versions: Fuji, Geneva, Helsinki and Istanbul (June 2017)
ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more. In this post we'll discuss how to use Centrify Identity Service to secure ServiceNow by using the Multi-provider SSO plugin. In subsequent posts we'll discuss provisioning, protecting shared credentials, using the Centrify ServiceNow store apps.
Why secure ServiceNow with Federated SSO?
There are multiple security and operations-related reasons to implement federated identity and SSO for ServiceNow. A key reason is related to the fact that SN is a SaaS platform, this means that the enterprise is extended and information is accesible outside the enterprise datacenter. Using federated SSO, allows the use for on-premises identity and access control to secure assets outside the enterprise. This provides the assurance that only authorized internal users can access those assets. Another reason is usability with SSO there's no need to duplicate passwords; finally there is the gains in operational efficiency by using a process (like adding a user to an AD group to provision access) or simply disabling the AD user account will disable access to ServiceNow automatically.
We'll use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:
What you'll need
- A Centrify Identity Service Instance
- A ServiceNow Instance or a Developer Instance (Fuji, Geneva or Helsinki)
- Administrative accounts on both systems
Here are some planning topics for your ServiceNow/Centrify Identity Service Integration
- What are the user populations that will have access to ServiceNow? (e.g. AD, LDAP, Google Directory, etc.)
- What will be the uniquely-identifying field to be used with the SAML assertion?
- What will be the name for the CIS Role? (e.g. SN Users)
- Is the Multi-provider SSO plugin activated in the instance?
- Will you use the Centrify-provided x.509 certificate?
Note: If you have an older tenant, the provided courtesy signing certificate might have been signed with the SHA1 algorithm. You may want to update to SHA256.
- Will the assertion be encrypted?
- Will provisioning be used? Are the SN groups created?
- Will the MPSSO with Centrify be set as default? Will passwords be eliminated?
- Will ServiceNow be accessible from inside or outside the enterprise? Will time or geo-fencing mechanisms will be implemented
- Should ServiceNow access be protected with multi-factor authentication?
- Will service provider-initiated (SP-initiated) connections be supported?
These are the high-level steps to configure Centrify Identity Service as a provider for SSO.
- In Identity Service: Create a Centrify Role that will be assigned the Centrify App
- In ServiceNow - Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin.
- In Identity Service - Onboard the "ServiceNow - SAML + Provisioning" template
- In ServiceNow - Import the x.509 Certificate for the SAML assertion
- In ServiceNow - Set-up, configure and enable the Identity Provider
- In Identity Service - Configure the ServiceNow App
Create a CIS role with the ServiceNow users
- Log in to the Centrify Identity Service Admin Portal with a user with at least role management rights.
- Go to Roles > Add Role; in the Description tab, give it a name.
- In the Members tab, select the users from the target directory or directories, then press Save
Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin
- Log into your ServiceNow instance with an administrative user
- In the Application Navigator (left pane), use the search feature and type "Plugins", this filters System Definition and click Plugins.
- Now in the right pane, next to System Plugins, in Name type "Integration - Multiple"
- Click on "Integration - Multiple Provides Single Sign-On Installer" (should be set as inactive, if it's not, skip to the next section)
- Under Related Links, Click "Activate/Upgrade" and Click Activate
- After activation, the "Multi-Provider SSO" Application will be activated in ServiceNow. This app contains these sections: Getting Started, Identity Providers, Federations and Administration.
Onboard the "ServiceNow - SAML + Provisioning" template
- Sign-in to Identity Service with a user that at least has the Application Management right.
- In the Admin Portal go to Apps > Add Web App, then search for "ServiceNow SAML + Provisioning"
- Click the Add button, confirm your selection and close the Add Web Apps window.
- In Identity Service, you'll be placed on the Application Settings tab for the ServiceNow app template, scroll down and click on Download Signing certificate
- Open a text editor in your platform (Notepad, TextEdit or Vi) and open the downloaded file. Copy the contents to memory.
(Note: the contents should be a PEM-encoded certificate)
Import the Certificate to the Multi-Provider SSO via x.509 Admin Module
- In ServiceNow > Multi-Provider SSO > Administration > x509 certs
- New Cert > Give it a unique name
- Format > PEM
- PEM Certificate > paste the contents of memory loaded in the previous section
- Press Save.
Configure the Identity Provider
- In ServiceNow > Multi-Provider SSO > Identity Providers
- Select New > SAML2 Update 1 > and when the "Import Identity Provider Metadata" pop-up comes up, select Cancel.
- At this point, you can use the table on this page to configure the settings. This is because it depends on your directory source and optional settings. Here's the configuration for a now decommissioned demo environment:
- The look and feel of the multi-provider SSO plugin varies between SN versions Fuji, Geneva and Helsinki.
- The identity provider has to be set to Active and default if you want Service-Provider initiated to be possible.
- The "Failed Requirement Redirect" is set to the same value as the "Identity Provider AuthnRequest."
- The location of the x.509 certificate options varies. You may have to save the identity provider first to see the option to select a certificate (e.g. Geneva, Helsinki, Istanbul), then update the identity provider.
- The default field option for the Identity Provider is email. Modify this setting based on your planning and identity source field mappings (e.g. in my case user_name)
- Once finished, press Save
Enable Multi-Provider SSO
- In the Multi-Provider SSO app , select the Properties module
- Check the "Yes" box under "Enable multiple provider SSO"
- Press Save. This completes the ServiceNow set-up for SSO.
(Optional) Enabling Service Provider Initiated (SP-Initiated) logins
There are two ways of doing this:
- Setting-up the Identity Provider for Centrify as default
- Setting-up the SSO Source at the company or user level
Here's an excerpt from: ServiceNow's documentation
Configure the ServiceNow App in Identity Service
- In Identity Service, go back to ServiceNow > Application Settings
- If you haven't, type in the instance ID under "Your ServiceNow instance name", then click on User Access
- Check the box next to the Centrify Role that was created in the planning phase. Click on Account Mapping
- Because in this example, we're using Active Directory as the user source, we are going to use "samaccountname"
Note: that's is the "username" field in Active Directory, therefore, the user ID in ServiceNow must match for each user.
This is one way to do it, there is flexibility here. Other common deployments use the email field.
- Testing your work in the Advanced page
Use the test button with some users in the target role to make sure that the assertion will be correct.
For testing, all you need to do is create an Active Directory Identity Service user and match the User ID in ServiceNow with the user's AD login name (samaccountname) and set it to active.
- In ServiceNow go to User Administration > Users
- Click New
- In User ID, type the username of a user (AD, Centrify, LDAP, Google).
For example, in my environment I'm using Lisa and I'm matching the UserID (user_name) with her Active Directory username (samaccountname).
- Since this will be an SSO user, there's no need to give it a password. Press Submit.
- Now we need to give the user a role. In the user list, click on the newly-created user and scroll down to Roles and press Edit.
- Give the user a role (e.g. ITIL, press Save) then Update the user.
In my example, I have a ServiceNow - ITIL Role in Identity Service, and this matches well.
- Identity-provider initiated login
This is when you launch the application from the Identity Provider's portal.
- Log in as your AD user, to the Identity Service User Portal.
You should see the user's assigned apps including ServiceNow
- Click on ServiceNow. You should be signed into ServiceNow without a challenge.
- Log in as your AD user, to the Identity Service User Portal.
- Service-provider initiated login
This is when you go directly to the application.
- Go to your instance URL and select external login.
- When you type-in the username, you'll either be re-directed to your Identity Service portal for authentication, or if you have a current session (or Kerberos ticket and IWA enabled), you'll be placed in the app.
Note that this behavior can be modified if the SN multi-provider SSO is set as default and or using the optional step above (enabling SP initiated) section.
Enhancing the Implementation
There are several areas for enhancement, but these come to mind:
- Enable Provisioning (next blog post)
- Enable multi-factor authentication
- Protect shared accounts
- Enable workflow and approvals
There are multiple resources available in the documentation and tech blogs:
- Identity Service ServiceNow Documentation
- How to set-up Centrify Identity Service for automatic provisioning into ServiceNow
- How to set up Centrify App Access for ServiceNow
- Video: Centrify and ServiceNow configuration overview by @Andy-Z
- Video: ServiceNow Application Access Request Overview by @Andy-Z
- Video: ServiceNow Application Access Request Walkthrough by @Andy-Z
- Video: Centrify Privileged Access Request for ServiceNow by @Andy-Z
- [Labs] Integrating ServiceNow Approvals to Centrify-enhanced sudo using the dzdo validator
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.