Need help understanding saml metatdata

Question

I'm integrating with a 3rd party and for the claims configuration, they recommended we create sAM-Account-Name to Name ID, and keep getting this error in the SAML response:

<samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />
    </samlp:StatusCode>
</samlp:Status>

So I assumed I was not sending the correctly formatted NameID. In the SP's metatdata, they have this listed:

<NameIDFormat>
    urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</NameIDFormat>

Rightly so, I assume I'm supposed to use the transient NameID format. However, that doesn't work either, and the vendor insists they expect our SAML response to use urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified as the Name ID format. From what I understand, that's default for ADFS.

As a test, I followed the steps here: https://blogs.msdn.microsoft.com/card/2010/02/17/name-identifiers-in-saml-assertions/ and was able to get a bogus NameID (transient) to pass to the vendor's site, where it then displayed back in the browser that the username was not valid, so at least I got something which makes me believe I'm on the right track and their authentication server is expecting transient while their application is not.

I would try the steps here, but I don't want to affect my whole claims provider: https://social.technet.microsoft.com/wiki/contents/articles/4038.ad-fs-2-0-how-to-request-a-specific-name-id-format-from-a-claims-provider-cp-during-saml-2-0-single-sign-on-sso.aspx

We're running Server 2012 R2 for our ADFS server. This isn't the first Relaying Party Trust we've configured, and our setup is working well with our other vendors. I however, am relatively new to managing ADFS, so I may have missed something simple.

Any thoughts or guidance would be appreciated.

Answer 1

If the claims mapping in ADFS for your relying party includes Active Directory samAccountName to SAML NameID, the "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" specified by the service provider's metadata doesn't really make a lot of sense as this value isn't transient.

As per the SAML v2.0 specification, the optional NameIDPolicy in the SAML authn request "specifies constraints on the name identifier to be used to represent the requested subject".

In practice, it's simpler to either not include a NameIDPolicy so it defaults to "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" or explicitly use this value.

Given the above, the NameIDFormat in the service provider's metadata can be safely ignored and NameIDPolicy not included in the authn request.

Answer 2

The the SP can deny a claim based on its format, which is ultimately the issue. The solution then is the SP should either change their requirements, or one must send the claim in the required format.

In this case, the SP is requiring the claim to be transient, even though they verbally require unspecified (default). Verbal claim requirements don't count when dealing with systems!

To get ADFS configured with this SP, one simply needs to:

• Create a transform rule, with the rule template: Send LDAP Attributes as Claims
  • LDAP attribute is SAM-Account-Name
  • Outgoing Claim Type is whatever you want it to be (custom text, not from the dropdown)
• Create another transform rule with the rule template: Transform an Incoming Claim
  • The incoming claim type is whatever your Outgoing Claim Type was previous.
  • The Outgoing claim type is then Name ID with the format as Transient Identifier.

This will allow the sAM-Account-Name to be sent to the SP with a transient format, even though we know that attribute is by definition, not transient.

See screenshots: