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:
https://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 https://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
We are using ADFS 2.0 to communicate with SAML 2.0. Now we would like to create a deep link to a timeline page with url:
https://myinstance.service-now.com/show_schedule_page.do?sysparm_page_schedule_type=timeline_page&sysparm_timeline_page_id=a854d37cf87d600013baee371c30cc0c
We have tried to use this link as the deep link:
https://myinstance.service-now.com/nav_to.do?uri=show_schedule.do%3Fsysparm_page_schedule_type%3Dtimeline_page%26sysparm_timeline_page_id%3Da854d37cf87d600013baee371c30cc0c
It does not work, unless the user already is logged in. The page displays the error message “One of the required fields was not specified. Make sure “sysparm_timeline_page_id” is specified.”. Deep linking works ok for other records, such as, incidents and requested items.
Anyone know what we are doing wrong?
Thanks,
Tomas
Tomas,
I’m experiencing the exact same issue as you. Would be great to catch-up if you make any progress, and vice-versa my side.
Thanks,
Pritam
Hi,
We are using serviceNow SAML 2.0 Single Sign On integration.The Metadata shared by the ADFS team says ‘urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
<SAML:Attribute Name= "User-Id" NameFormat= "urn:oasis:names:tc:SAML2.0:attrname-format:basic"
But in ServiceNow at our end we have configured in the NamePolicy ID
urn:oasis:names:tc:SAML:1.1:nameid-format:user_name
Can you please suggest, do we need to configure some additional settings in servicenow if the XML file is passing Attribute Name instead of NameIDFormat
Thanks,
Pushkal
@Pushkai – We do need to use the NameID Format in the SAML AuthnRequest and SAML Response. The SAML properties page allows you to set the NameID Format urn string. Once you have that set, then the Metadata generator link should indicate that to ADFS. ADFS will then need to be configured to respond with the nameID format and match the policy that you are expecting. That is about all I can tell you from here without actually looking at your setup.
Hello James,
We followed the document which is available on internet to configure ADFS and SNOW.
We have a shared instance on SNOW cloud. Multiple customers are configured on SNOW.
The ADFS idp initiated login brings up a page where it asks us to login to ServiceNow. Once we click on the option it brings another page and asks us to login . We login using the domain credentials. This takes us to the SNow instance login page. this asks us for email identification and then brings up the SNOW login page.I provide domain user name and password. But it doesn’t accept it and says invalid. Clearly SSO isn’t working.
SNOW has my name configured in SNOW console with my email address and without any password. In AD, I have my email address with the same value as in SNOW.(We do not host our Exchange it’s on OFC365)
BTW I am using ADFS 3.0 setup for our federation with SNOW.We use SNOW Calgary. Would you be able to help?
Hi there, I desire to subscribe for this webpage to get hottest updates, therefore where can i do it please assist.