Configuring ADFS 3.0 to Communicate with SAML 2.0

From ServiceNow Wiki
Home > Integrate > Single Sign-On > SAML > Configuring ADFS 3.0 to Communicate with SAML 2.0
Jump to: navigation, search

Note: This article applies to Fuji. For more current information, see ADFS Integration with SAML 2.0 at

The ServiceNow Wiki is no longer being updated. Please refer to for the latest product documentation.

1 Overview

SAML 2.0 single sign-on (SSO) supports integration with Microsoft Active Directory Federation Services (ADFS) 3.0.

2 General ADFS Setup

This procedure uses ADFS 3.0 and shows as the ADFS website. Replace this with your ADFS website address.

  1. Log into the ADFS server and open the management console.
  2. Right-click Service and choose Edit Federation Service Properties....
    Editing federation services properties

  3. Confirm that the General settings match your DNS entries and certificate names. Take note of the Federation Service Identifier, since that is used in the Service-Now SAML 2.0 configuration settings.
    Federation Service Identifier

  4. Browse to the certificates and export the Token-Signing certificate.
    a. Right-click the certificate and select View Certificate.
    b. Select the Details tab.
    c. Click Copy to File….
    The Certificate Export Wizard launches.
    d. Select Next.
    e. Ensure No, do not export the private key is select, and then click Next.
    f. Select DER encoded binary X.509 (.cer), and then click Next.
    g. Select where you want to save the file and give it a name. Click Next.
    h. Select Finish.
    Service-now requires that this certificate be in PEM format. You can convert this certificate using client tools or even online tools such as: SSL Shopper.
  5. Use the DER/Binary certificate we just created and export it to Standard PEM format.

3 ServiceNow Settings

  1. If not already active, contact ServiceNow Technical Support to activate the SAML 2.0 Single Sign-On plugin.
  2. Configure SAML 2.0.
  3. For Step 5. Install the IdP Certificate attach the PEM certificate we created earlier.
  4. Click Save.
  5. Verify that the Issue and Subject fields have values and that there are no errors. If an error occurs, open the saved PEM formatted certificate in Notepad and copy and paste the certificate into the PEM Certificate field.
  6. Verify that the SAML2SingleSignon_update1 installation exit is active.
  7. Continue the SAML 2.0 configuration.
Note: When a certificate is updated on the ADFS server, you also need to upload an updated certificate to the instance.

4 ADFS Relying Party Configuration

At this point you can take the ServiceNow Metadata and import it into your ADFS server. However, manual configuration of the relying party appears to be easier to implement.

  1. Navigate to SAML 2 Single Sign-on > Properties and verify that the SAML property Sign AuthnRequest (glide.authenticate.sso.saml2.require_signed_authnrequest) is not active. Only keep this property active if your ADFS administrator can verify that you require signed requests.
  2. Copy the metadata that you generated through the SAML 2 metadata link and save it to a file.
  3. Open the ADFS Management console and select Relying Party Trusts.
  4. Select Add Relying Party Trust… from the top right corner of the window.
    The add wizard appears.
  5. Click Start to begin.
  6. Use the Import File option to import the metadata file.
  7. Give it a display name such as ServiceNow and enter any notes you want.
  8. Select ADFS 3.0 Profile.
  9. Do not select a token encryption certificate.
    It will use the certificate that is defined on the service that has already been exported. Defining a certificate here will prevent proper communication with ServiceNow.
  10. Do not enable any settings on the Configure URL.
  11. Enter the ServiceNow Web site to which you connected as the Relying Party trust identifier. In this case use and click Add.
  12. Permit all users to access this relying party.
  13. Click Next and clear the Open the Claims when this finishes check box.
  14. Close this page.
    The new relying party trust appears in the window.
  15. Right-click on the relying party trust and select Properties.
  16. Browse to the Advanced tab and set the Secure hash algorithm to SHA-1.
  17. Browse to the Endpoints tab and add a SAML Assertion Consumer with a Post binding and a URL of

5 ADFS Relying Party Claim Rules

Edit the Claim rules to enable proper communication with Service-Now.

  1. Right-click on the relying party trust and select Edit Claim Rules….
  2. On the Issuance Transform Rules tab select Add Rules….
  3. Select Send LDAP Attribute as Claims as the claim rule template to use.
  4. Give the claim a name such as Get LDAP Attributes.
  5. Set the Attribute Store to Active Directory, the LDAP Attribute to E-Mail-Addresses, and the Outgoing Claim Type to E-mail Address.

    Editing a rule

  6. Select Finish.
  7. Select Add Rule….
  8. Select Transform an Incoming Claim as the claim rule template to use.
  9. Give it a name such as Email to Name ID.
    Incoming claim type should be E-mail Address (it must match the Outgoing Claim Type in rule #1. The Outgoing claim type is Name ID (this is requested in ServiceNow policy urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress) and the Outgoing name ID format is Email. Pass through all claim values and click Finish.

    Editing a rule

  10. If you edit the existing rule and click View Rule Language…, they should match the following:

Rule #1:

c:[Type == "", Issuer == "AD AUTHORITY"]  
=> issue(store = "Active Directory", 
types = (""), 
query = ";mail;{0}", param = c.Value);

Rule #2:

c:[Type == ""]
 => issue(Type = "", 
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, 
= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

6 Single Logout Support

To create a SAML logout endpoint in your RP trust configuration in ADFS:

  1. Go to ADFS manager > Trust Relationships > Relying Party Trusts > properties.
  2. Under the Endpoints tab, click Add.
  3. Configure the settings:
    • Endpoint Type: SAML Logout
    • Binding: POST
    • URL:

7 Logging into ADFS

  1. Open Internet Explorer and browse to
    This opens a generic page with a drop down list of all Relying Party Trusts configured.
  2. Select the one you want to log in to and click on Continue to Sign In.
    This only work if you have enabled SSO on the ServiceNow web page. If it is configured properly, you are logged in.
  3. To create a direct link so users do not need to select from a drop down list, browse to

8 Workaround: Enabling Service Provider-Initiated Authentication

Customers who have not applied SAML 2.0 Update 1 can have authentication fail if users attempt to skip IdP authentication and navigate directly to the ServiceNow instance. This is an error with ServiceNow not providing ADFS with the needed definition and semantics for the SPNameQualifier attribute in the SAMLResponse.

To enable Service Provider-initiated authentication, do one of the following:

  • Upgrade to SAML 2.0 Update 1 and clear the option to create an AuthnContextClass request.
  • Modify the SAML2 script include to comment out the definitions of the SPNameQualifier attribute when you have SAML 2.0 active (not SAML 2.0 Update 1).

Change these lines in the createNameID and createNameIDPolicy functions:


To this:


If you do not want the login prompt from your ADFS server to appear when you access the instance, set the following SAML 2.0 Update 1 property to false: Create an AuthnContextClass request in the AuthnRequest statement (glide.authenticate.sso.saml2.createrequestedauthncontext). See SAML properties for more information.

9 Workaround: Supporting Kerberos Authentication

Currently, the SAML 2 integration uses a PasswordProtectedTransport or “forms-based authentication” authentication context. This authentication context requires the IdP to present users with a form for authentication credentials. With Kerberos, a SAML session is already active through an established Windows login, so the user does not need to authenticate with the IdP.

The following example applies a workaround to the SAML 2.0 integration that changes the authentication context from “forms-based authentication” to "Windows-based authentication."

  1. Navigate to SAML 2 Single Sign-on > Properties.
  2. Search for the following Properties:
    Property: Create an AuthnContextClass request in the AuthnRequest statement. - Set this to "Yes" to force which one you want
    If you Set this to "No" the IdP will decide which is the best.

    Property: The AuthnContextClassRef method that we will be included in our SAML 2.0 AuthnRequest to the Identity Provider:
    Set this to one of the following values:
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport (Default)
  3. Click Update.

10 Video Tutorial

This video how to configure ADFS 2.0 to communicate with the SAML 2.0 single sign-on functionality of ServiceNow. This applies to Eureka and earlier releases.

How to Configure ADFS 2.0 to Communicate with SAML 2.0
Was this article helpful?
Yes, I found what I needed
No, I need more assistance