Error "No peer endpoint available to which to send SAML response" with Shibboleth/SAML auth

[Riccardo Murri]

Hello,

we are trying to set up Shibboleth authentication on a server running "Cypress".
The SAML backends seem to be running fine and no tracebacks appear in the logs.

The login process starts fine: when clicking "Use your University credentials"
the browser is correctly redirected to the University's IdP, the usual
login form is displayed.
Upon entering the credentials, however, the IdP displays an error message
"No peer endpoint available to which to send SAML response".

What should we look for to debug the error? We know the IdP is
working correctly,
because other Shibboleth-enabled services allow login. The IdP is
the University
of Zurich's one, belonging to the SWITCHaai Shibboleth federation
(https://www.switch.ch/aai/guides/)

Thanks for any help!

Kind regards,
Riccardo

--
Riccardo Murri
http://www.s3it.uzh.ch/about/team/#Riccardo.Murri

S3IT: Services and Support for Science IT
University of Zurich
Winterthurerstrasse 190, CH-8057 Zürich (Switzerland)
Tel: +41 44 635 4297
Fax: +41 44 635 6888

[Kelketek Rritaa]

Hello Riccardo!

The person on our team who knows the most about this is predisposed, unfortunately. I'll try to help you out, however :)

You may wish to look here:
https://shibboleth.usc.edu/docs/idp/errors/

The error message you mention is listed, and the info they give is:

This message indicates a mismatch between the configuration of the USC Identity Provider and the application you tried logging in to. Specifically, an invalid Assertion Consumer Service URL was requested by the application.

This message used to appear as "Invalid assertion consumer service URL".

As I understand it, this likely means that the configuration being sent to the Shibboleth provider either doesn't contain an endpoint URL to the LMS or the URL is invalid. You may wish to look inside of your handler.xml file to see if the URLs pointing toward your LMS make sense.

[Kelketek Rritaa]

I received a bigger hint from our expert, Braden:

They can see the ACS URL by going to (their LMS URL)/auth/saml/metadata.xml - it should contain a part that says <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://my-lm-sserver.com/auth/complete/tpa-saml/" index="1"/>
Whatever the domain is in the metadata (http://my-lm-sserver.com here) must be the same as the domain of the login page (http://my-lm-sserver.com/login) from which they are testing. If they're on a devstack using a non-standard port or nginx proxying, make sure the port numbers match are in all of the URLs - the metadata and the browser.

On Wednesday, September 16, 2015 at 4:37:37 AM UTC-5, Riccardo Murri wrote:

[Filippo Panessa]

>> They can see the ACS URL by going to (their LMS
>> URL)/auth/saml/metadata.xml - it should contain a part that says
>> <md:AssertionConsumerService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>> Location="http://my-lm-sserver.com/auth/complete/tpa-saml/" index="1"/>

Our metadata.xml is here https://edx-test.s3it.uzh.ch/auth/saml/metadata.xml

<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

Location="http://130.60.24.227/auth/complete/tpa-saml/" index="1"/>

>> Whatever the domain is in the metadata (http://my-lm-sserver.com here)
>> must be the same as the domain of the login page
>> (http://my-lm-sserver.com/login) from which they are testing. If they're on
>> a devstack using a non-standard port or nginx proxying, make sure the port
>> numbers match are in all of the URLs - the metadata and the browser.

We have IP in metadata, not domain.

--
Filippo Panessa

[Kelketek Rritaa]

Have you checked in your configuration to see where you may have placed the IP instead of the domain? It’s likely rejecting that IP because it needs to have a match with the real domain. Take a look in your SamlProviderConfig, SamlConfiguration, and your lms.env.json for any places where the IP may have been specified instead of the domain name.

> --
> You received this message because you are subscribed to a topic in the Google Groups "Open edX operations" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openedx-ops/Ij_Oga3C8W0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openedx-ops...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openedx-ops/CAMmNHRHeuBJYQySGrkHmTHJCt6%2BAVjASztuahTrWLicSmvq4ow%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Alok Daipuria]

Your Service Provider configuration in your IdP server is not matching with what your LMS is configured with. Check your SP Metadata file on IdP end to make sure the URL is matching your LMS URL. Looks like IdP authenticated fine, but it does not know where to send back the response.

 Hope this helps...