I recently had a seemingly simple task for a customer to set up an ADFS 2016 relying party trust for their SailPoint IdentityNow deployment. Sounds easy right?

In this scenario, ADFS 2016 was to be the Identity Provider (IdP) and IdentityNow the Service Provider (SP). Our end-goal of the solution was to allow the customer’s users to authenticate via SAML into IdentityNow using their corporate ADFS email address and password. Great outcome from a user experience perspective and for corporate governance too!

Configuration Set up and Problem Encountered

Following SailPoint’s guide here I set up IdentityNow as a Service Provider using the Email attribute as the SAML NameID.

I then moved onto creating a new ADFS 2016 relying party trust using the sp-metadata.xml file downloaded directly from the customer’s IdentityNow portal. After some quick research of the claims required I created the following 2x ADFS Issuance Transform Rules within my new RPT:

  • Rule #1: Send LDAP Attribute (E-Mail-Addresses) as an Outgoing Claim (E-Mail Address)

  • Rule #2 Transform an Incoming Claim (E-Mail Address) to an Outgoing Claim (Name ID) with the Outgoing name ID format (Email)

Unfortunately during my testing, I was continually returned the following web page message from the customer’s IdentityNow portal. 

This was occurring after the initial ADFS authentication and token being issued.

Whilst the web page error is vague in its description of the error, I knew that because the initial ADFS authentication had succeeded that I was dealing with a claims issue between the IdP and SP. 

InvalidNameIDPolicy SAML Response

Diving into the SAML response using Fiddler and a SAML decoder I could see a SAML status code of “InvalidNameIDPolicy“. Problem discovered! The most useful and easily accessible diagnostic information was actually straight out of the ADFS server’s local event viewer logs under Applications and Services Logs > ADFS > Admin (in hindsight I should have looked there first!).

Events #364 and #321 also verified that the NameIDPolicy required from IdentityNow was not being met by the AD FS token issued.

Event ID #364

 Encountered error during federation passive request. 

 The SAML request contained a NameIDPolicy that was not satisfied by the issued token.

 

 Event ID #321

 The SAML authentication request had a NameID Policy that could not be satisfied.

Tip: If you encounter the same problem I had, have a look at the detail of these two events and compare the Requested NameIDPolicy versus the Actual NameIDPolicy to discover what exactly is missing from the AD FS token.

Sending SPNameQualifier as a Claim

The resolution to this problem for me was to ensure that a SPNameQualifier value was sent as a claim property from ADFS to IdentityNow.

As far as I know, this is an undocumented requirement to have SAML authentication tokens from ADFS 2016 accepted by SailPoint IdentityNow.

The SPNameQualifier value needed to match the Entity ID specified in our IdentityNow portal under Admin > Global > Security Settings > Service Provider.

Because I couldn’t find SPNameQualifier property in any of the Claim rule templates I used a Custom Rule which you can create as shown below.

The following Claim rule combines my original Rule #2 (described at the beginning of this post) with the new claim property for SPNameQualifier.

Note: If using the below claim code remember to replace “insertValueHere” with your Entity ID specified in IdentityNow.

After updating my claim rule with the above change a quick test of authenticating to IdentityNow via ADFS SAML was successful and I could also finally see SAML authentication events from the IdentityNow Activity Tab.

Happy days! 

Summary

In conclusion when configuring SAML authentication via ADFS 2016 (IdP) to IdentityNow (SP) you may need to insert a SPNameQualifier value as an outgoing claim property from AD FS. The SPNameQualifier value should match the Entity ID value specified in your IdentityNow portal.

Cheers, Jesse