Problem Description #

I maintain two .NET 4.7.2 web apps implementing SAML2 SSO. One authentication flow works perfectly, but the other consistently throws this error:

ID4037: The key needed to verify the signature could not be resolved from the following security key identifier.

Here's the full stack trace:

at System.IdentityModel.EnvelopedSignatureReader.ResolveSigningCredentials()
at System.IdentityModel.EnvelopedSignatureReader.OnEndOfRootElement()
at System.IdentityModel.EnvelopedSignatureReader.Read()
at System.Xml.XmlReader.ReadEndElement()
at System.IdentityModel.Tokens.Saml2SecurityTokenHandler.ReadAssertion(XmlReader reader)
at System.IdentityModel.Tokens.Saml2SecurityTokenHandler.ReadToken(XmlReader reader)
at ITfoxtec.Identity.Saml2.Saml2AuthnResponse.ReadSecurityToken(XmlNode assertionElement)
at ITfoxtec.Identity.Saml2.Saml2AuthnResponse.Read(String xml, Boolean validateXmlSignature)
at ITfoxtec.Identity.Saml2.Saml2PostBinding.Read(HttpRequest request, Saml2Request saml2RequestResponse, String messageName, Boolean validateXmlSignature)
at ITfoxtec.Identity.Saml2.Saml2Binding`1.ReadSamlResponse(HttpRequest request, Saml2Response saml2Response)

Key Details: #

• Local testing: Unit tests with SAML messages pass without issues.
• Test server issues: Verification fails consistently in the test environment.
• Certificate checks: Confirmed correct certificates are used, included in SAML messages, and even swapped certificates to rule out certificate-specific problems—same error persists.
• Custom token resolver: I created and configured a custom TokenResolver based on examining the Saml2AuthnResponse.ReadSecurityToken method and .NET's EnvelopedSignatureReader.ResolveSigningCredentials logic, but I can't confirm if it's being invoked, and the error remains.
• Environment context: The test server is part of a larger application ecosystem, so I suspect configuration/setting issues or server-level problems, but I'm not sure which specific items to adjust.

Troubleshooting & Solution Ideas #

Let's break this down step by step—since you control both ends and it works locally, the issue is almost certainly environment-specific configuration or server-level constraints.

1. Verify Custom Token Resolver is Actually Being Used #

First, confirm your custom resolver is hooked up correctly. Add debug logging (or temporarily throw a debug exception) in your resolver's ResolveToken method to see if it's being called at all.

In .NET 4.7.2, when using ITfoxtec.Identity.Saml2, you need to ensure you're assigning the resolver to the Saml2SecurityTokenHandler's TokenResolver property before processing the response. Here's a quick check:

var saml2Handler = new Saml2SecurityTokenHandler();
saml2Handler.TokenResolver = new YourCustomTokenResolver();
// Assign this handler to your Saml2AuthnResponse if you're overriding the default

If it's not being called, your resolver isn't properly integrated—double-check where you're configuring security handlers in your pipeline.

2. Check Server-Level Certificate Permissions #

Even if the certificate is present on the test server, the application pool identity might not have permission to access its private key.

• Open Certificates (Local Computer) → navigate to your certificate.
• Right-click → All Tasks → Manage Private Keys.
• Ensure the application pool's identity (e.g., IIS AppPool\YourAppPoolName) has Read permissions on the private key.

Local dev environments often run under your user account (which has full permissions), but test servers use restricted app pool identities—this is a super common gotcha.

3. Validate SAML Message Key Identifier Format #

Sometimes the key identifier in the SAML assertion uses a format that the default resolver doesn't handle correctly in the test environment (even if it works locally).

• Capture the SAML assertion XML from the test server (use browser dev tools or a proxy like Fiddler to inspect the POST request).
• Look for the <ds:KeyInfo> element in the assertion. Check if the key identifier is a thumbprint, subject name, or something else.
• Ensure your custom resolver can handle the exact format present in the test message. For example, if the test server uses a subject name identifier but your resolver only looks for thumbprints, that would cause the error.

4. Check for Machine.config or Server-Level Security Configuration Overrides #

Test servers might have machine-level configuration changes that override your app's settings.

• Compare the machine.config on your dev machine vs. the test server (located in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config for 32-bit, or Framework64 for 64-bit).
• Look for sections like <system.identityModel> or <system.serviceModel> that might be adding global token resolvers or security settings conflicting with your app's configuration.

5. Enable Detailed SAML Logging #

ITfoxtec.Identity.Saml2 has built-in logging capabilities that can give you more insight into what's happening during verification.

Add logging configuration to your web.config:

<system.diagnostics>
  <sources>
    <source name="ITfoxtec.Identity.Saml2" switchValue="Verbose">
      <listeners>
        <add name="fileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="saml-log.txt" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Check the log file after reproducing the error—it might show exactly which key identifier it's trying to resolve and why it's failing.

6. Test with Explicit Certificate Loading #

Instead of relying on automatic key resolution, try explicitly loading the certificate in your code and passing it to the SAML handler. This bypasses the resolver and confirms if the certificate is accessible.

var cert = new X509Certificate2("path-to-cert.pfx", "password");
var saml2AuthnResponse = new Saml2AuthnResponse(config);
saml2AuthnResponse.SignatureValidationCertificates.Add(cert);

If this works, the issue is definitely with the token resolver not finding the certificate—go back to verifying your resolver's logic and integration.

内容的提问来源于stack exchange，提问作者Jesse Sierks