...

Although this is presented by the Velocity library as an ERROR level message, this can be ignored. The message merely indicates that the fallback from Velocity to JSP is occurring. You may wish to filter it with your logging configuration.

Common Error Screens

The login service was unable to identify a compatible way to respond to the requested application...

This is a human translation of the EndpointResolutionFailed event in the IdP that triggers when the basic check between the 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 AssertionConsumerServiceURL attribute in 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).

Whatever its set to, that URL generally has to be one of the <AssertionConsumerService> endpoints in the SP's metadata used by the IdP or this error message is returned by default in response to the error and the IdP log records the problem.

As an IdP operator you either have bad metadata, or you have a broken SP, and unless you created the metadata, 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.

Miscellaneous issues

IdP stops sending authentication statements after 2 weeks; restarting the IdP temporarily resolves the issue

...