Infinite looping of SP in load balanced production instance

Brian Reindel brian at reindel.com
Thu Oct 31 01:36:07 EDT 2013


So this ended up not being the case, at least not as simply as I
described it. What it continues to come down to is how we should be
configuring our SP behind the load balancer. It is taking all https
traffic from the outside and proxying it to http within the network.
I'm really struggling with how the SP should be configured given the
scenario. This pretty closely describes our situation
https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy in
terms of how things look to be routed. Right now all our protocols in
the SP metadata are https, and in Shibboleth2.xml for the SP we have
handlerSSL set to false, and the cookieProps has the "secure" setting.
I've attempted to mimic this as best I can in my local environment by
using secure apache as a reverse proxy over to non secure, and I do
end up getting the same error we now get in production. It is the "No
peer endpoint available to which to send SAML response" error, which
in the logs is the "...requested the response to be returned to
endpoint with ACS URL... however no endpoint, with that URL and using
a supported binding,  can be found in the relying party's metadata..."
error. The only difference between the URLs is one is https and the
other is http.

Any guidance on this would be appreciated.


On Tue, Oct 29, 2013 at 6:55 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 10/29/13, 6:46 PM, "Brian Reindel" <brian at reindel.com> wrote:
>
>>Ah, I think I get what you're saying, and actually I may have found the
>>issue based upon the feedback. It all has to do with how we protected
>>the SP context within Apache, which may have inadvertently protected
>>Shibboleth.sso as well. I will know for sure tomorrow.
>
> That's the definite "cause", but normally that's not easy to do unless the
> SP is incapable of accurately computing the handler that applies to a
> request, so that isn't likely to be the only issue. It may be possible to
> avoid fixing the underlying issue by exempting the handler URL tree though.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list