ADFS don't pass claims from Ws-Fed response from Claim Provider to outgoing SAML response for RP - asp.net-core

Question

In my environment there are an ADFS 4.0 and asp.net project with IdentityServer4 + WsFederation package as the Claim Provider. All RPs that using a Ws-Fed protocol work fine. But SAMLP RP, does not receive claims in the response.
Sequencing:
The RP initiates a SAML signin request in ADFS. ADFS makes a Ws-Fed singin request to IdentityServer4. ADFS Get Ws-Fed response with a propper claims. But on the next step when ADFS generate SAML response from Ws-Fed response, ADFS issues the SAML response for RP without a claims ...
There is an error in event log:
EventID: 303:
Additional Data
Exception details:
System.IdentityModel.Tokens.SecurityTokenException: MSIS7099: SubjectConfirmationData element was missing in received token.
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.ValidateRequestProperties(Saml2SecurityToken token)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
Ws-Fed message with UPN and E-mail claims:
<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"
Context="RPUrl=http://xxxxxx.com%2fadfs%2fservices%2ftrust\BaseUrl=http%3a%2f%2fxxxxxxxx.com%2fadfs%2fservices%2ftrust\ProtocolID=Saml\Id=id-8cbbc2e6-70f5-4804-9e61-99fd13781978\SAMLRequest=xxxxxxxx%3d\ProtocolBinding=urn%3aoasis%3anames%3atc%3aSAML%3a2.0%3abindings%3aHTTP-Redirect\RelayState=8e27a614-61b2-47f0-9583-f9be1d9ee75a"
>
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>http://xxxxxxxx.xxxxxxxxx.com/adfs/services/trust</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<t:RequestedSecurityToken>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_aac09822-5db4-4791-b677-690ef5bf273e"
IssueInstant="2020-07-01T14:10:26.357Z"
Version="2.0"
>
<Issuer>https://xxxxxxxxxx.xxxxxxxxxxx.com</Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="#_aac09822-5db4-4791-b677-690ef5bf273e">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>/2MHUXKcVJHSzV70wbFJVFrnYawDdFYPuekSh1/zEC4=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>xxxxxxxxxx</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>xxxxxxxxx</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">xxxxxxxx</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>
<Conditions NotBefore="2020-07-01T14:10:26.357Z"
NotOnOrAfter="2020-07-02T00:10:26.357Z"
>
<AudienceRestriction>
<Audience>http://xxxxxxx.xxxxxxxx.com/adfs/services/trust</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn">
<AttributeValue>xxxxxxxxx</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>xxxxxxxxxx</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2020-07-01T14:10:26.342Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</t:RequestedSecurityToken>
</t:RequestSecurityTokenResponse>
WS-Fed -> SAML (UPN and E-mail are missing):
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_59eef1fa-81c5-4ede-8538-6caf4dbdf480"
Version="2.0"
IssueInstant="2020-07-01T14:10:26.698Z"
Destination="xxxxxxxxx/adfs/ls/"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="id-7052d47f-3df0-4d49-8ddf-673603bccb8e"
>
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">xxxxxxxx/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_59eef1fa-81c5-4ede-8538-6caf4dbdf480">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>iia3AYaxxx8UoxILqjhsxkgeO4rXqPk9Jil1t0jUbLU=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>xxxxxxxx</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>xxxxxxxxxxxxxxxxxx</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
</samlp:Status>
</samlp:Response>
Has anyone encountered a similar one?

Answer 1

The "urn:oasis:names:tc:SAML:2.0:status:Responder" is an error status. The SAML response will contain a SAML assertion with the various claims as the SAML Subject and SAML attributes only if successful.
Check the Windows event log on the ADFS server. There will be one or more error events associated with this error. It's most likely some sort of configuration error.

Answer 2

It sounds like you are not passing through the claims.
You need pass-through rules on the WS-Fed CP side and the same set of pass-through rules on the SAML RP side.
Since WS-Fed doesn't use NameID, you may also have to contruct a NameID claim on the SAML side using e.g. email or UPN.

Answer 3

The error was that IdentityServer4 generates a SAML 2.0 token inside the WsFederation message by default instead of SAML 1.1. Everything worked well until the applications initiated the WsFederation SignIn request, and extract SAML token by itself, but when the application sent the SAML SingIn request the ADFS must extract the SAML token but ADFS works with SAML 1.1 version only. So as a solution I switched a token version from SAML 2.0 to SAML 1.1 in IdentityServer4 and all started work.
namespace IdentityServer4.WsFederation
{
public class WsFederationOptions
{
//public string DefaultTokenType { get; set; } = WsFederationConstants.TokenTypes.Saml2TokenProfile11; // was
public string DefaultTokenType { get; set; } = WsFederationConstants.TokenTypes.OasisWssSaml11TokenProfile11; // working way
...
}
}