The XML failed to validate against the SAML XML Schemas

We are just going live with our “new” SAML implementation using ComponentSpace for ASP.NET Core, and porting over all of our external partner identity providers (we are the service provider.) When sending a SAML request to a certain IDP and receiving the SAML response back from them, we are intermittently experiencing an exception thrown by the ComponentSpace package. Interestingly, if I try multiple SSO requests within a few minutes T, a couple may work and then the third one may fail, then they will work again, so it’s very random. Also, it’s only happening for one IDP, hundreds of others are working perfectly fine 100% of the time.

ComponentSpace.Saml2.Exceptions.SamlSchemaValidationException: The XML failed to validate against the SAML XML Schemas. at ComponentSpace.Saml2.SamlProvider.ValidateXml(XmlElement xmlElement) at ComponentSpace.Saml2.SamlServiceProvider.ReceiveSsoAsync() at Rpr.Websites.Auth.SsoController.ChallengeSamlCallback() in C:\agent1_work\1\s\Websites\Auth\Controllers\SsoController.cs:line 286

We have logging in place so we can see the actual SAML response that is tripping this exception, and it’s a legitimate and valid SAML response, indicating a success from the IDP. (some values ommitted)

<samlp:Response ID=“4f49b29b-ca99-4cee-b19b-5a33121f9db3” InResponseTo=“_d8294736-e9dc-4bc5-a35c-70db30c6381b” Version=“2.0” IssueInstant=“2022-04-27T20:23:22.549Z” xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol”><saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>http://www.theirdomain.com</saml:Issuer><Signature xmlns=“<CanonicalizationMethod”>http://www.w3.org/2000/09/xmldsig#“><CanonicalizationMethod Algorithm=”<a href=“http://www.w3.org/2001/10/xml-exc-c14n#”“>http://www.w3.org/2001/10/xml-exc-c14n#” /><SignatureMethod Algorithm=“<a href=“http://www.w3.org/2000/09/xmldsig#rsa-sha1"”>http://www.w3.org/2000/09/xmldsig#rsa-sha1” /><Transform Algorithm=“<a href=“http://www.w3.org/2000/09/xmldsig#enveloped-signature””>http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm=“<InclusiveNamespaces”>http://www.w3.org/2001/10/xml-exc-c14n#“><InclusiveNamespaces PrefixList=”#default samlp saml ds xs xsi" xmlns=“<a href=“http://www.w3.org/2001/10/xml-exc-c14n#””>http://www.w3.org/2001/10/xml-exc-c14n#“ /><DigestMethod Algorithm=”<a href=“http://www.w3.org/2000/09/xmldsig#sha1"”>http://www.w3.org/2000/09/xmldsig#sha1" />YcfprbTHtR1kfBL4bGHKlQ+egAE=samlp:Status<samlp:StatusCode Value=“urn:oasis:names:tc:SAML:2.0:status:Success” /></samlp:Status><saml:Assertion Version=“2.0” ID=“_410dc552-9716-492c-baab-64570b826f43” IssueInstant=“2022-04-27T20:23:22.549Z” xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>saml:Issuerhttp://www.theirdomain.com</saml:Issuer>saml:Subject<saml:SubjectConfirmation Method=“urn:oasis:names:tc:SAML:2.0:cm:bearer”><saml:SubjectConfirmationData Recipient=“<a href=“https://ourdomain.com/v2/sso/challenge/saml/callback””>https://ourdomain.com/v2/sso/challenge/saml/callback" InResponseTo=“_d8294736-e9dc-4bc5-a35c-70db30c6381b” /></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore=“2022-04-27T20:23:22.549Z” NotOnOrAfter=“2022-04-27T20:33:22.549Z”>saml:AudienceRestrictionsaml:Audiencehttps://www.ourdomain.com</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant=“2022-04-27T20:23:22.549Z”>saml:AuthnContextsaml:AuthnContextClassRefurn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement>saml:AttributeStatement<saml:Attribute Name=“AgentID” NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified” FriendlyName=“AgentID”>saml:AttributeValueTEST123</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>

For comparison, here is a nearly identical SAML response from the same IDP that was successful and didn’t throw any exceptions:

<samlp:Response ID=“e37cf3ab-b3c5-4b4b-ab84-2ccaab850f5c” InResponseTo=“_d9bdb1d8-f48a-4a92-8846-f857084aa29c” Version=“2.0” IssueInstant=“2022-04-27T20:13:26.423Z” xmlns:samlp=“urn:oasis:names:tc:SAML:2.0:protocol”><saml:Issuer xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>http://www.theirdomain.com</saml:Issuer><Signature xmlns=“<CanonicalizationMethod”>http://www.w3.org/2000/09/xmldsig#“><CanonicalizationMethod Algorithm=”<a href=“http://www.w3.org/2001/10/xml-exc-c14n#”“>http://www.w3.org/2001/10/xml-exc-c14n#” /><SignatureMethod Algorithm=“<a href=“http://www.w3.org/2000/09/xmldsig#rsa-sha1"”>http://www.w3.org/2000/09/xmldsig#rsa-sha1” /><Transform Algorithm=“<a href=“http://www.w3.org/2000/09/xmldsig#enveloped-signature””>http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm=“<InclusiveNamespaces”>http://www.w3.org/2001/10/xml-exc-c14n#“><InclusiveNamespaces PrefixList=”#default samlp saml ds xs xsi" xmlns=“<a href=“http://www.w3.org/2001/10/xml-exc-c14n#””>http://www.w3.org/2001/10/xml-exc-c14n#“ /><DigestMethod Algorithm=”<a href=“http://www.w3.org/2000/09/xmldsig#sha1"”>http://www.w3.org/2000/09/xmldsig#sha1" />qxHSNX+MytFAKjspNuvMk3Q/raI=samlp:Status<samlp:StatusCode Value=“urn:oasis:names:tc:SAML:2.0:status:Success” /></samlp:Status><saml:Assertion Version=“2.0” ID=“_507643cc-9603-4d3f-99c9-84b49168bbd3” IssueInstant=“2022-04-27T20:13:26.423Z” xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>saml:Issuerhttp://www.theirdomain.com</saml:Issuer>saml:Subject<saml:SubjectConfirmation Method=“urn:oasis:names:tc:SAML:2.0:cm:bearer”><saml:SubjectConfirmationData Recipient=“<a href=“https://ourdomain.com/v2/sso/challenge/saml/callback””>https://ourdomain.com/v2/sso/challenge/saml/callback" InResponseTo=“_d9bdb1d8-f48a-4a92-8846-f857084aa29c” /></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore=“2022-04-27T20:13:26.423Z” NotOnOrAfter=“2022-04-27T20:23:26.423Z”>saml:AudienceRestrictionsaml:Audiencehttps://www.ourdomain.com</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant=“2022-04-27T20:13:26.423Z”>saml:AuthnContextsaml:AuthnContextClassRefurn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement>saml:AttributeStatement<saml:Attribute Name=“AgentID” NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified” FriendlyName=“AgentID”>saml:AttributeValueTest123</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>

Here is the relevant code (abbreviated) that is throwing the exception:

[HttpPost(
“challenge/saml/callback”)]

public async Task ChallengeSamlCallback()

{

// Validate and parse the SAML response.

var result = await _samlServiceProvider.ReceiveSsoAsync();

}


The exception message seems to be inaccurate, and furthermore doesn’t contain any additional information to act upon. Can you please advise how I go about resolving the “The XML failed to validate against the SAML XML Schemas” error?

We validate the XML against the XML schema documents that are part of the SAML specification. Given it happens intermittently, perhaps there’s a particular value in the SAML response that’s causing the issue.

Please send both the unsuccessful and successful SAML responses as separate email attachments to support@componentspace.com mentioning your forum post. Please don’t alter the XML.

Also, when you get the chance, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com. We’d like to see both successful and unsuccessful examples.

https://www.componentspace.com/forums/7936/Enabling-SAML-Trace