SAML Authentication Request NameID Policy Issue – Windows Server 2016 ADFS

adfssamlwindows-server-2016

I'm using Issuance Policy as:

Rule 1:

Rule 2 (custom):

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", 
Issuer = c.Issuer, 
OriginalIssuer = c.OriginalIssuer, 
Value = c.Value, 
ValueType = c.ValueType,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "https://fs.hhres.com/adfs/services/trust", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "sp_test");

When I try to login, it gives me error (from Event Viewer)-

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

Requestor: BambooHR-SAML

Name identifier format:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
SPNameQualifier:

Exception details: MSIS7070: The SAML request contained a
NameIDPolicy that was not satisfied by the issued token. Requested
NameIDPolicy: AllowCreate: True Format:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
SPNameQualifier: . Actual NameID properties: Format:
urn:oasis:names:tc:SAML:2.0:nameid-format:transient, NameQualifier:
https://adfs_url/adfs/services/trust SPNameQualifier: sp_test,
SPProvidedId: .

This request failed.

User Action Use the AD FS Management snap-in to configure the
configuration that emits the required name identifier.

Can someone please explain what I'm doing wrong and what needs to be done?

Best Answer

I resolved this by changing the line-

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

into

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",

Related Solutions

Send NameID claim without encryption in ADFS 2.0

We had a customer with an issue connecting to our web application. We wanted to disable encryption to help debug what we were receiving. These are the steps they used to disable encryption on their ADFS 2.0 server:

Click Start
Click Administrative Tools
Click Windows PowerShell Modules

Then, at the Windows PowerShell command prompt, type the following:

set-ADFSRelyingPartyTrust –TargetName “target” –EncryptClaims $False

ADFS v.2.0 transitive trust in a federation scenario

Well, since nobody did answer, i took the time, setup a test lab and sniffed the HTTPS traffic. Here are my research results in case anybody else will ever come across this thing:

I still got no official source for this questions
First off: yes, transitive trust is possible and there is no way to block it except of legal affairs. A propper SLA is the basis for any federation scenario anyways.
There is no special "setting" to disable or enable it, but using the claims rule engine a trusted partner may configure ANY kind of outgoing claims IF ANY kind of incomming claims are detected, so there is no way to "protect" illegal access.
In my tests, none of the rule templates that come with ADFS changed the OriginalIssuer property of the claims. One may think: Okay so i can use that property to verify the original source of any claim and build a filter to only allow claims comming directly from (and not traversed through, which by default only affects the Issuer but not the OriginalIssuer property) a trusted partner. But thats wrong, why? Look at the next line.
As i said, the default templates don't touch the OriginalIssuer property. But you may create custom rules using the rule engine. Using that one, you can change pretty much every claim type, value and their properties. And yes: also the OriginalIssuer. So to the federation provider it looks as the claims are comming directy from the trusted partner, where in reality they're only transformed there.

So, what i would suggest to atleast minimize "transitive" scenarios if they're unwanted, is to check for the OriginalIssuer. It dosn't protect from transitive logins, but a admin would have to explicitly configure it - which would make legal affiars much more easier in a case of SLA voilation. Also, i'm not thinking of the possibility to change the OriginalIssuer as a "bug", in fact: even without that feature, every thrid party software could always make it able to act as a proxy between backend systems and the trusted identity provider. For example the IdP could create shadow accounts for partner (C) - so there will always be a workaround since when using federation, you're giving away the control on who is able to delegate access rights to specific ressources.

Anyway - if you have been as curious as i about how ADFS 2.0 handles transitive trusts, now you know without the need to build a testlab and sniff HTTPS traffic.

Related Topic