Fixing SP Initiated Login with ADFS 2.0 and ServiceNow SAML
A few months ago I worked with a client to get AD FS 2.0 working with SAML 2.0 in a situation where ServiceNow is the Service Provider. However, at the time, we were unable to get an SP-initiated authentication scenario to work between SeviceNow and AD FS.
I recently came across some articles which keyed me into a probable cause of the SP-Initiated Authentication failures.
When someone tries to get to their ServiceNow instance in an unauthenticated state by going to their instance url (eg. https://myinstance.service-now.com), they would be redirected to the IdP login page. During that redirection, ServiceNow sends a SAML AuthnRequest so that the IdP will know how to process the login.
In the request, ServiceNow was sending the following NameID format element:
1 2 3 | <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" SPNameQualifier="https://myinstance.service-now.com/navpage.do" /> |
AD FS, however was responding that ServiceNow was sending an invalid NameIDPolicy.
After reading the SAML 2.0 Assertion Specification document, I came across the following text on lines 424-432:
NameQualifier [Optional]
The security or administrative domain that qualifies the identifier. This attribute provides a means to federate identifiers from disparate user stores without collision.
SPNameQualifier [Optional]
Further qualifies an identifier with the name of a service provider or affiliation of providers. This attribute provides an additional means to federate identifiers on the basis of the relying party or parties.The NameQualifier and SPNameQualifier attributes SHOULD be omitted unless the identifier’s type definition explicitly defines their use and semantics.
This led me to believe that maybe the SPNameQualifier attribute could be causing errors with AD FS since we are not explicitly defining the use and semantics.
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. You only need to change the properties on the SAML Properties page.
To fix this issue, I visited the “SAML2″ Script Include and commented out two lines of code where we set the SPNameQualifier in the SAMLRequest.
In the “createNameID” function I commented out the following line:
//nid.setSPNameQualifier(serviceURL);
In the “createNameIDPolicy” function I commented out the following:
//nameIdPolicy.setSPNameQualifier(serviceURLStr);
Once I had saved this library I was able to perform an SP-initiated SAML authentication between ServiceNow and AD FS 2.0.
Hi John,
Congrats on solving this! It’s implemented and works. I was taking advantage of the relative calm between christmas and new year to troubleshoot this exact issue amd your post finally solves it.
Best regards and happy holidays
Richard
Thanks for being the brave soul to try this out so quickly! That makes two clients in a row.
Lost of clients have also had problems with SingleLogout. I worked with someone recently that was able to get it working for their environment. Hoping to have that solution up today or tomorrow. If you have had problems with logout you’ll have to check it out and let me know if it makes sense to you, and to see if it works.
Thanks again for following my blog Richard.
Hi John,
We’ve made the changes as described, however, we’re still having the same issue as before. Our ADFS is returning an error stating that the request needs to be signed. We followed the instructions for getting our instance running in IDP, and the SSO is working properly IDP (with the exception of deep linking). We made this change in an attempt to get deep linking working, but it was not successful. Is there something else that we need to do to be able to get SP working even though the SAML request is not signed?
I don’t know the settings required on the ADFS side to not require signed requests. ServiceNow does not currently sign their requests, and the steps we took with ADFS did not require signing either. You may wish to do some searches on ADFS and signed requests. Before I cobbled together my ADFS notes for SAML, I was on a call with a Microsoft AD architect and I asked him if ADFS required Signed Requests and he confirmed that it did not.
Hi Scott,
Just to confirm, you don’t have any certificates listed under RP > Right mouse click>Signature tab, do you?
Brgds
Richard
Hi John
Thank you for this post.
As we removed these 2 lines we made a step further SSO.
If I now connect to our instance we got redirected to the ADFS and are asked to enter user/pass. Now, this works to login to SNC.
But how can I do this without log in with my user credentials? I mean connecting to the SNC instance and getting logged in automatically, without entering some user data.
Thank you and best regards
Andreas
Andreas,
If an authenticated ADFS session exists in the browser, then it should authenticate you without the credentials. However, if the SAML session is terminated at your ADFS endpoint then you will have to log in again. I believe this is a configuration issue on the ADFS side. We redirect to them and they determine if credentials need to be input or if an existing session will suffice.
-John
Hi Richard,
I’m not the one who administers ADFS, but i’ve been told that we don’t have any signature verification specified for the relying party trust.
Andreas,
It may also depend on settings within your ADFS. We experience this type of behaviour when attempting to authenticate using ADFS, when the user is in Firefox or Chrome. The authentication should run flawlessly in Internet explorer, but for the other major browsers, there is an extended protection setting on ADFS that you need to disable.
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
Scott,
Did you find a root cause why you need to enter your username and password again in ADFS. We have exactly the same problem here at our client (also using Internet Explorer).
Regards,
Roel
Hi Roel,
We aren’t having any issue when we’re logging in using Internet explorer, we have recurring issues when we try to hit the ADFS IDP link from Chrome and Firefox when using the SAML 2.0 plugin.
Scott (and Andreas),
I am sorry for the confusion, since my question should have been asked to Andreas. I see that Andreas describes in his post on January 16, 2012 at 6:34 am, the same problem as we are having. Therefore:
@ Andreas, did you find a root cause why you need to enter your username and password again in ADFS? When going to our SNC-instance, we are also asked to put in our username/pw in ADFS (we expect an automatic login).
For those of you using Kerberos and hoping to bypass an ADFS login form during SAML SSO with ServiceNow, you may wish to check the following post I just created:
http://www.john-james-andersen.com/blog/service-now/supporting-kerberos-authentication-with-adfs-in-servicenow.html
John,
Thanks for the post. This was exactly the problem we were running into.
Roel
Hi guys
Thank you very much, it works now perfectly.
This article and this one helped http://www.john-james-andersen.com/blog/service-now/supporting-kerberos-authentication-with-adfs-in-servicenow.html
Thank you for your help, I appreciate it very much.
Regards
Andreas
We are currently setting up SAML 2.0 and ADFS authentication. It worked perfectly at first, but now it doesn’t.
We have noticed that no authentication requests is sent from SNC to ADFS and the script debug output looks like this:
Query String (qs): null
URI Parameter: null
Stripping down the serviceURL: https://myinstance.service-now.com/navpage.do to a base URL of: https://myinstance.service-now.com
No Deep Linking for this SAML request
requestURI: /
Generating a Relay State of: https://myinstance.service-now.com/navpage.do
Is this a common behaviour? I have applied the update set and configured SAML according to the instructions…
Thanks,
Tomas