Unable to locate a SAML 2.0 ACS endpoint to use for response

[Peter Schober]

* Mr. Christopher Bland <chris at fdu.edu> [2017-06-16 03:50]:
> I am troubleshooting a cluster of SPs behind a load balancer and
> keep getting "Unable to locate a SAML 2.0 ACS endpoint to use for
> response”

All prior warnings and the context for that error message might be
relevant.

> <MetadataProvider type="Chaining">
>   <MetadataProvider type="XML" url="https://identity-provider/idp/profile/Metadata/SAML" backingFilePath="idp-metadata.xml"/>
>   <MetadataProvider type="XML" url="https://dev_identity-provider/idp/profile/Metadata/SAML" backingFilePath="idpdev-metadata.xml"/>
> </MetadataProvider>

Note that the wrapping "Chaining" provider is unnecessary, and more
gravely, that the above is rather insecure (unless you're willing to
bet that TLS alone will be good enough, no matter what kind of
metadata get's served there, with how many entityIDs, etc.)

If the servers/entities you're downloading metadata from are not your
own, you'd better add an entity whitelist filter to those, too,
otherwise these IDPs (or servers, or anyone in between managing to
MITM this connection) could impersonate anything and anyone to your
SP.
If those entities are your own I'd question the need for such
dynamicity and either supply those as local, verified, static files,
or maybe add some config management tooling to distribute those.
Finally, you (or the producer of this metadata) could also sign the
metadata (though you may still want to add a filter, to only let
expected entityIDs pass).

> I believe I made the correct changes based on documentation and
> example-shibboleth2.xml file but it doesn’t work.

If you've literally been changing the file example-shibboleth2.xml
then "it doesn't work" is the expected result of such action:
example-shibboleth2.xml is not used by the software by default (hence
the name), but shibboleth2.xml is.

-peter