no peer endpoint available to which to send SAML response

[Cantor, Scott]

On 8/22/13 8:53 PM, "Brian Tingle" <Brian.Tingle at ucop.edu> wrote:

>Not hearing anything back from UC Trust after filing my paperwork, I have
>asked around and found out there is an undocumented procedure where I
>have to try to identify a Shibboleth sponsor on each campus where I need
>attribute release who can work with the campus IdP to get us set up.

Well, there's no procedure of any sort, that's out of scope really. If
people choose to deploy IdPs and lock them down, then there's not a lot
you can do about that but beg, which not a lot of people are going to
waste their time doing. There are simply classes of IdP deployments, some
that are designed for broad usage and some designed for only
explicit/specialized use.

Frankly, the biggest asset of the InCommon R&S concept is probably the
notion of tagging the *IdPs* that are willing to play ball. We haven't
stumbled on a clean way of addressing that in a more general capacity.

But for any given service that *has* to get certain IdPs to work, it
really needs to be part of a larger relationship.

>My first campus sponsor reports that they can access one of my
>applications, but not the other.  For the application where they cannot
>log in, they report an error "no peer endpoint available to which to send
>SAML response"

Either your metadata is incorrect in some way, or they have some kind of
issue acquiring it.

> and I see messages such as
>
>
>shib_handler: Invalid HTTP method (GET).
>shib_handler: remoted message returned an error: Unable to establish
>security of incoming assertion.
>shib_handler: Unable to establish security of incoming assertion.
>shib_handler: remoted message returned an error: Request missing SAMLart
>query string or form parameter.
>shib_handler: Request missing SAMLart query string or form parameter.

I can't think of why anything would be using artifact endpoints, so
something seems to be wrong with your metadata.

>there are also entires in transaction.log around the time he tried to log
>in

That's a bug related to logging of SAML errors returned by IdPs. Which
doesn't match with an IdP throwing an error about the endpoint, which
doesn't ever return anything to the SP.

-- Scott