If 2011 was the year of ADFS SAML 2.0 implementations in ServiceNow, then 2012 looks like it will be the year of Kerberos Authentication with ADFS and ServiceNow.

Over the past few weeks I have had a number of customers contact me regarding better support of their Kerberos authentication when they are using ADFS and SAML to do Single Sign-on with ServiceNow.

Thanks to some help from Microsoft, and a lot of coordination from a client in Switzerland, we have been able to provide better support for users who are logging into ServiceNow via Kerberos authentication with Windows.

The idea behind Kerberos authentication is that when you authenticate to the Windows desktop, you are establishing a SAML session. If someone browses to ServiceNow and they don’t have an active ServiceNow session, the SAML should detect that they have a SAML session alive through Kerberos and automatically authenticate the user into ServiceNow without having to type ADFS credentials.

However, with the current setup, regardless of the user having a SAML session via Kerberos, ServiceNow would redirect to the IdP and the IdP would display the ADFS login screen. It wasn’t detecting the Kerberos session.

The reason behind this situation is that the ServiceNow SAML plugin supports PasswordProtectedTransport for it’s authentication context. This is also known as “forms-based authentication”. This tells the IdP that the user should be presented a form by the IdP where they should authenticate. However, with Kerberos, the SAML session is already active through an established Windows login, so the user shouldn’t have to be presented a form for authentication.

The bad news here is that ServiceNow SAML 2.0 does not support Windows authentication out of the box. The good news, however, is that it is an easy customization.

The Theory

SAML has an attribute that tells the IdP what type of authentication we are expecting them to perform in order to qualify a user. This attribute is the AuthnContextClassRef. This element takes a URN string that identifies that method.

As mentioned previously, the PasswordProtectedTransport method indicates that we require form-based authentication. The string used to identify that is: 

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

The Windows authentication methodology is specified by using this string:

urn:federation:authentication:windows

This tells the ADFS IdP that we are expecting that they try their Windows login in order to validate the authentication of a given user.

The Solution

New Update: If you download the update set that provides Additional SAML 2.0 Configuration Options then you will not need to modify the SAML scripts as outlined below.

In order to enjoy the full benefits of a Kerberos authentication setup with ADFS, perform the following steps:

1) Perform the steps outlined in my blog post: AD FS 2.0 working with ServiceNow SAML 2.0

2) Apply the fix outlined in Fixing SP Initiated Login with ADFS 2.0 and ServiceNow SAML

3) Modify the SAML “Script Object” according to these instructions:

Browse to the SAML application in ServiceNow and click on the “Script Object” module.

In the script that comes up, find the following line:

1
authnContextClassRef.setAuthnContextClassRef("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport");

Comment out that line and add a new line as seen below:

1
2
//authnContextClassRef.setAuthnContextClassRef("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport");
authnContextClassRef.setAuthnContextClassRef("urn:federation:authentication:windows");

Then, save the script.

Disclaimer

As this is not out of the box code for the ServiceNow SAML 2.0 plugin, it has not been thoroughly tested by a large number of users. Please use at your own risk.

Please also understand that by modifying an out-of-the-box script such as this, you will not automatically get future updates applied to this script.