Single Sign on a ServiceNow stand-alone Instance

OverviewSingle Sign-on(SSO) is the gateway that enables access to multiple software systems.It is a
type of External authentication, wherein a user needs to login once, and can access multiple
software application resources without logging in again and again in every software.Single
Sign-on(SSO) utilizes the LightWeight Directory Access Protocol(LDAP) for providing access
to the multiple applications to the user.This is beneficial in the large organizations where it is
difficult to manage multiple databases for user records.So, a single user database is
sufficient for SSO.
Process Flow-

Figure 1:- Process Flow of Single Sign-on (SSO)

Configuring SSO via SAML 2.0 Web Browser SSO ProfileService Now has provided SAML 2.0 plugin for implementation of Single Sign-on(SSO) as
external security for accessing resources of multiple software systems.Security assertion
markup language(SAML) is responsible for exchanging security information between
IDP(Identity Provider) and Service Provider. The Identity Provider(IDP) passes the NameID
tokento Service-Now instance for authenticating the user, if Service-Now had a user with the
same NameID token, then the access is provided to that user.
Steps to implement SSO integration (SAML 2.0) for Service Now:
1. Activating the SSO application plugin(SAML 2.0).

2.
3.
4.
5.
6.

Identity Proider(SAML 2.0) will be available.

Configure the Service Now instance URLs.
Must provide a NameID Policy.
Installing the certificate from Identity Provider(IDP) metadata.
Share the Service Provider (SP) metadata.

Step 1: Activating the SSO application plugin(SAML 2.0).

Contact Service Now customer support by calling at their Customer Support number
or by raising a ticket on HI system to request for the activation of latest SAML 2.0
Single Sign-On plugin.

SAML 2.0 plugin installs the application named SAML 2 Single Sign-on as shown
below

Step 2: Identity Proider(SAML 2.0) will be available.

Identity Provider will provide the metadata(authentication & logout) in the XML format
document.

The property by the name- Enable external authentication or the system

property by the name- glide.authenticate.external should be set as True on the
SAML 2.0 Single Sign-on Properties

Browse through the metadata of Identity Provider to find the values for the following
properties:
1. From the metadata file, the entry having the entity ID on the first URL should be
put on the IDP Property by the name- The Identity Provider URL which will

issue the SAML2 security token with user info. The equivalent system
property by this name is- glide.authenticate.sso.saml2.idp.
From the metadata file attached on the document, the Entity ID can be seen as
depicted belowclient-internal-LP-saml2

2. From the metadata file, the entry having the Single Sign on Service element with
a Binding attribute that contains a value of HTTP-Redirect or the Location
attribute comprising of the URL which the integration uses for the Authentication
Request service should be entered in the Property by the name- The base URL
to the Identity Providers AuthnRequest Service. The AuthnRequest will
be posted to this URL as the SAMLRequest Parameter. The equivalent
system
property
by
this
name
isglide.authenticate.sso.saml2.idp_authnrequest_url.

From the metadata file attached on the document, the value on the property
can be seen as depicted belowhttps://ifed.client.com:9031/idp/SSO.saml2

3. From the metadata file, the entry having the Single logout Service element with a
Binding attribute that contains a value of HTTP-Redirect or the Location attribute
comprising of the URL which the integration uses for the Single Logout Request
service should be put in the Property by the name- The base URL to the
Identity Providers SingleLogoutRequest Service. The LogoutRequest will
be posted to this URL as the SAMLRequest Parameter. The equivalent
system
property
by
this
name
isglide.authenticate.sso.saml2.idp_logout_url.
From the metadata file attached on the document, the value on the property can
be seen as depicted belowhttps://ifed.client.com:9031/idp/SSO.saml2

4. The Property by the name- Sign AuthnRequest. Set this Property to True if
the Identity Providers Single sign on Service requires Signed
AuthnRequest or the system property by the name
glide.authenticate.sso.saml2.require_signed_authnrequest should be set
as False.

5. If your Identity Provider(IDP) uses a signed logout request then select Yes in the
property named Sign LogoutRequest. Set this property to true if the
Identity Provider's SingleLogoutRequest service requires signed
LogoutRequest, else select No if the IDP uses unsigned logout requests.

6. If the identity provider requires a signed logout request, then in the property by
the name The protocol binding for the Identidy Providers
SingleLogoutRequest service, you need to enter one value from the following
2 supported values listed, which are listed in the binding attribute.
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
In our case, we have used an HTTP-Redirect binding.

7. Enter the URL obtained from the Single Sign On Service element for HTTPRedirect binding in the property named When SAML 2.0 single sign-on fails
because the session is not authenticated, or this is the first login,
redirect to this URL. This is the base URL where the initial SAML 2.0
AuthnRequest is sent using the SAMLRequest parameter.
From the metadata file attached on the document, the value on the property
can be seen as depicted belowhttps://ifed.client.com:9031/idp/SSO.saml2

8. Enter the URL in the property named URL to redirect users after logout,
typically back to the portal that enabled the SSO, where you want to
redirect users after they successfully logout.

Step 3: Configure the Service Now instance URLs.

Enter the URL of the instance for which the identity provider(IDP) authenticates in
the property named The URL to the Service-now instance (usually this
instance). e.g:-

Enter the base URL which the IDP will authenticate in the property named The
entity identification, or the issuer. e.g :-

Step 4: Must provide a NameID Policy.

Enter the name of the field in the property named as The User table field to
match with the Subjects NameID element in SAMLResponse, which will be
used to search for the matching value in the token(IDP shares this token with SP for
authentication of the user).Here we have used user_name field for matching with
the NameID token.e.g :-

Specify the NameID policy as supported by the Identity Provider.Enter the

NameIDFormat value in the property named The NameID policy to use for
returning the Subject's NameID in the SAMLResponse. e.g :-

Step 5: Installing the certificate from Identity Provider(IDP) metadata

For validation, IDP(Identity Provider) utilizes a certificate for communicating with the
SP(Service Provider). On both Identity provider and the ServiceNow instance, you

will have to install the same certificate. IDPs certificate will be available within the
identity providers metadata.
Navigate
to
ds:X509Certificate
element
in
Identity
Providers
metadata.And copy the value of this element(i.e IDPs certificate).
Browse to certificate module SAML 2 Single Sign-on > Certificate in
Service Now.
In PEM Certificate field on the form remove the existing content between
Begin
Certificate
and
End
Certificate
and
paste
the
IDPs
certificate(ds:X509Certificate) contents in place of that as copied in above
steps.
The name of the certificate in Service Now instance must be SAML 2.0 by
default. Please dont change the name as this is used by the integration to
work. e.g :-

Step 6: Share the Service Provider (SP) metadata.

For sharing Service Provider metadata(which SSO integration generates automatically) with
the Identity Provider, navigate to the module SAML 2 Single Sign-on > Metadata, and
from there copy the metadata to share with the IDP. e.g :-

Reference(s)
1. http://wiki.servicenow.com
2. http://www.youtube.com