Over the past few months I have had a number of clients contact me with issues regarding SAML 2.0. Due to the complexity of SAML 2.0, and the plethora of options associated with the specification, there are obviously many differences between IdP’s. What works for one, doesn’t always work for another.

I have taken the customizations suggested in my blog over the past few months and combined them into an update set that can be applied to enhance the configuration capabilities of your SAML 2.0 plugin in ServiceNow.

Deprecation Notice

This solution should only be used with Aspen versions of ServiceNow and earlier. ServiceNow wrapped this update set into their SAML 2.0 Update 1 plugin and made it available in the Berlin release. Please do not leverage this solution for the more recent versions of ServiceNow.

The New Settings

Here is the breakdown on some of the new settings:

Send the SP Name Qualifier attribute with the NameID Policy in our SAML 2.0 requests.
This setting allows you tell ServiceNow not to set a SP Name Qualifier attribute on our NameID Policy in the AuthnRequest statement. It is optional by SAML specifications. ADFS and Shibboleth both do not accept the statement as it has been implemented by ServiceNow. You can typically set this to “False” and be better off. It defaults to true simply to be backward compatible for people already using the SAML 2.0 plugin.

Create an AuthnContextClass request in the AuthnRequest statement.
The AuthnContextClass attribute is typically sent by default in the original plugin. This attribute tells the IdP that ServiceNow requires that they use a specific type of authentication for a user. Shibboleth, and ADFS in some situations, don’t like to be told how they should present their authentication to the user on their own IdP. Usually it is an environmental situation with Kerberos, or Proxy servers. You can now choose not to require a specific type of authentication mechanism and just let the IdP decide this.

The AuthnContextClassRef method that we will request in our SAML 2.0 AutnReqeust to the Identity Provider
If you do want to tell the IdP what type of authentication to present the user, then you can also specific what that type is. By default we have always sent a PasswordProtectedTransport requirement which is essential a form-based authentication page. However, you can allow the IdP to use their Kerberos setup by specifying urn:federation:authentication:windows as the context class ref. This setting lets you specify that as a configuration setting rather than by modifying the SAML scripts.

Other Enhancements

Unique SAML ID
In the past, ServiceNow has been sending the browser Session ID as the SAML request ID. However, the SAML specification states that this ID field needs to be unique for EVERY request. This ID can then be used by the IdP to help prevent replay attacks. This update set makes that ID unique for every SAML request that is sent by the system.

Making the AuthnRequest function scriptable
Most users won’t need this, but I have some ideas for a future integration, but it requires some flexibility in changing the AuthnRequest parameters based on a situation rather than on an instance. I made some changes that will facilitate that in the future if we ever go down that route.

Hardcoded attributes can be set via properties
There are a number of hard coded properties in our SAML statements. They are hard coded for a good reason. However, if there are any situations where we need to deviate from the default to support a new IdP, it would be nice to be able to create a property that overrides the hard coded attribute. Where I could safely, I changed most hard coded attributes to be override-able via system properties if necessary.

Handle Null Prefixes in SAML Response
Site-Minder and potentially other IdP’s do not provide a namespace prefix on their SAMLResponse when it comes back to ServiceNow. In these cases, the authentication process would always fail with ServiceNow, even after the user authenticated against the IdP. I modified the SAML code to handle this situation gracefully so that we can support Site-Minder SAML out of the box.

The Update Set

I will be working with the ServiceNow development team to get these changes into the plugin so that this update set won’t be necessary in the future. However, I have several clients that need these settings today. If you need some of the settings explained above, feel free to download the update set and give it a try. Please note that if you do use the update set, you do so at your own risk as this is not part of the product and is not covered by technical support. However, if something does seem to break, slip me a pizza and I might offer personal support of my own.

Download

SAML 2.0 Additional Config Options