...

If you're using Tomcat, this issue is discussed on the (old) prep page along with some workarounds, primarily forcing it to expand the warfile, counter to the usual advice we give with Jetty.

...

This is a human translation of the EndpointResolutionFailed event in the IdP that triggers when the basic check between the the AssertionConsumerServiceURL in an SP's AssertionConsumerServiceURL in its request is not in the SP's metadata, so the IdP fails the request in accordance with the standard's requirement to validate the response location.

Most SAML SPs, and certainly most or all Shibboleth SPs, will include a full full AssertionConsumerServiceURL attribute in their AuthnRequest their <AuthnRequest> message to the IdP. The value of the URL in a Shibboleth SP is determined by the computed request URL that led to the issuance of the request and is primarily a function of web server configuration (on Apache) or the SP's <ISAPI> site mapping configuration (on IIS).

...

As an IdP operator you either have bad metadata, or you have a broken SP, and unless you created manage the metadata yourself (likely in the case of a commercial SP), it's not your problem to solve. Only the SP operator knows whether the URL is valid, so you may have to update the metadata or they will have to stop generating requests including the bad URL. The cause of a bad URL is generally a failure to properly configure a web server running the SP to account for local virtualization, load balancing, etc. It could also simply be a failure to update metadata to reflect a change that the SP deployer has made.

Common Log Messages

 org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to acquire conversation lock after 30 seconds

...