No peer endpoint available to which to send SAML response

[Peter Schober]

* voyage_34 <stefanos.pliakos at gmail.com> [2014-06-23 13:39]:
> I have a working IDP/SP configuration, but suddenly requirements have
> changed. We have registered our site with AKAMAI which does not allow reply
> from IDP to https for the SP.

I don't know what this means. The error message and config snippets
you've sent are from the Shibboleth IDP and SP software. What role
does Akamai play here for the exchange of SAML protocol messages?

> https://HOST/Shibboleth.sso/SAML2/POST for my SP when i have handlerSSL=true
> (which is normal i guess). When i try to change to handlerSSL=false i get
> the error "No peer endpoint available to which to send SAML response". I
> would like for the IDP to return something like
> http://HOST/Shibboleth.sso/SAML2/POST
> Is that possible? And what should i change in that case?

The IDP does not "return" an endpoint where the SP wants SAML protocol
messages to be sent, the SP /requests/ that endpoint and the IDP
merely verifies that against the SAML metadata it has on record for
that SP.
So if the IDP is unhappy about the missing http-URL then that's
because the metadata the IDP used does not contain those http
endpoints. (That itself is a function of how you import SAML metadata
about the SP into the IDP, see below.)

The error is independent from the SP's handlerSSL="true". Setting this
to false only will cause errors when the SP's handler is accessed via
plain HTTP.

Note that unless your IDP also runs on plain HTTP (meaning all
authentication from subjects to your IDP happens unencrypted on the
transport layer) using the HTTP-POST binding with non-TLS URLs will
cause security warnings in most web browsers (i.e., always when
POSTing from HTTPS to HTTP). There might be some tricks to work around
that but without those all users will be promoted with a security
warning on each login to such an SP. Many find this inacceptable, so
HTTPS on the SP is usually required. Of course without HTTPS on the SP
the SP's (or any applications') session cookies are also unprotected,
making it trivial for someone on your network to take over your
session with the SP and/or any applications it protects.

In short: handlerSSL="false" and http://HOST/Shibboleth.sso/SAML2/POST
is a bad idea.

> relying-party.xml (IDP):
>         <metadata:MetadataProvider id="COM2CERT"
> xsi:type="metadata:FileBackedHTTPMetadataProvider"
>                         metadataURL="https://HOST/Shibboleth.sso/Metadata"

Have a look at that URL, note the comment at the top of that resource.
Also note that if you throw out even the last bit of "security" here
and access the SP's metadata handler over plain http, the handler will
auto-generate SAML protocol endpoint URLs with plain http.
While that does what you're have been asking for literally , it is
certainly not what you should be doing.
-peter