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.
i am setting failed redirect URL in service now but SSO is not redirecting failed requests to this URL.
Hi John,
We are currently setting up the SSO with the SAML 2.0 update 1 plugin and Siteminder. I am trying to configure ServiceNow according to the instructions, but get “Could not validate SAMLResponse” in the script log.
Do you know if there is anything special to consider when configuring the SAML 2.0 update 1 plugin to communicate with Siteminder?
Thanks,
Tomas
We finally got it to work. It was simple in the end. Just had to get all the URL’s right.
I think the update 1 is a great improvement of the SAML 2.0 plugin.
/Tomas
Hi Tomas, we are getting the same error. What did you have to do to fix?
Thanks,
Mike
Are there any conflicts with Berlin Hotfix 5?
When we went from Aspen to Belin, our SAML intergration stopped functing. Once we re back on line, we had an issue with spNameQualifier so I have commented that out in our script include.
@Jim – There should be no conflicts between Aspen and Berlin that I am aware of. The SAML code does not change between those to unless you enable the “SAML 2.0 Update 1” plugin.
Hi, I’m having the same problem
We can successfully do SSO via IdP initiated, but not SP initiated.
Receive errors about Could Not Validate SAML Response, and InvalidNameIDPolicy.
I am using the SAML 2.0 Update 1 plugin, haven’t really touched anything in the configuration thus far.
Should I apply the update set? It seems to be older than the Update 1.
@Pablo – Don’t apply this update set if you are using “SAML 2.0 Update 1”. This update set was consumed into that new SAML 2.0 Update 1 plugin.
The issue you are facing is likely some sort of mismatch between the settings in ServiceNow and your IDP.
Hi all
i face same problem too any solutions thanks
Hans