Audience restriction doesn't match

SAML for ASP.NET Core
1

Hello
I’m using the latest SAML2 component for .net core and I could use it to integrate various IDPs.

I’m having an issue with the last one and I’m getting the following error :

The audience restriction https://XXX/security/xlogin/AssertionConsumerService doesn’t match the expected audience restriction https://XXX/.

My metadata are defined as following :

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://XXX/" ID="_b40cec4c-22b9-40bb-afe9-1da9ded46a5a"> <md:SPSSODescriptor ID="_6f27b819-a009-4e3d-b7e9-824dc3c10952" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" AuthnRequestsSigned="true" WantAssertionsSigned="true"> <md:KeyDescriptor> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</md:KeyDescriptor>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://XXX/security/xlogin/AssertionConsumerService" index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>

If I check the log I can see in the response :

<saml2:AudienceRestriction><saml2:Audience>https://XXX/security/xlogin/AssertionConsumerService</saml2:Audience></saml2:AudienceRestriction>

My diagnostic is that the IDP is using the endpoint URL in place of the Entity Id. In fact they are using an old technology and are not using metadata.xml at all, the only piece they are using for configuration are the certificate file and the endpoint url.

Of course if I disable audience restriction check, everything is working fine, but this is supposed to be a security breach.

Is there a way to fine tune this check? Should I simply hack my EntityID for this specific IDP?

2

We check the audience restriction in the SAML assertion against the LocalServiceProviderConfiguration.Name. If they’re not the same we throw the exception you’re seeing.

The LocalServiceProviderConfiguration.Name corresponds to the entity ID in the SP’s SAML metadata.

As you’ve determined, it looks like the IdP is using your assertion consumer service URL instead of your entity ID.

This isn’t standard practice and doesn’t strictly follow the SAML specification.

I recommend asking the IdP to send your entity ID for the audience restriction.

If they can’t, you will need to disable this check. It’s better not to disable these security checks but sometimes it’s unavoidable for compatibility reasons and I don’t believe disabling the audience restriction check will cause any significant issues.

3

Thank you for the answer, at least it confirms that it’s non standard.
I can’t disable the check, even if it won’t cause significant issues because this provider is an important one related to health information :expressionless:

So I’ve updated my dynamic configuration to use that weird entityID.
Kind regards

4

That sounds like a reasonable approach.

As per the SAML specification, the audience restriction URI should be the service provider’s entity ID. However, we have on occasions seen an IdP use the assertion consumer service URL instead.

I can’t think of any security issues if we were to accept the assertion consumer service URL.

We’ll discuss this internally next week and may add support for accepting either the SP’s configured entity ID or assertion consumer service URL as the audience restriction URI.

Assuming we make this change, please contact us via email if you’re interested in trying a beta release.