Troubleshooting the "Unable to decode" (IdP 3.3)

[Brent Putman]

On 8/30/17 4:35 PM, Cantor, Scott wrote:
> It's been corrupted beforehand, which I can identify for two reasons:
>
> - there's a SigAlg parameter but no Signature parameter
> - the SAMLRequest value is not URL encoded

Ah!  I forgot about the URL encoding.

>
> If you take the SAMLRequest alone, and URL encode that, and then reconstruct a URL to the IdP, it does not fail in the decoding process.

Ok, thanks.  Dodged a bullet on that one.  I was not looking forward to
trying to decode some low-level compression algorithm problem in code
that isn't even ours. :-)

>
> So, either the log itself is not an accurate reflection, or the request to the server is already corrupt by then. 

Since the request into the IdP is indeed failing, I think we have to
assume the latter.  Is there any kind of reverse proxying here, or
HA/LB device in front of the IdP, or something like that?  That's where
I would think to look next.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170830/c8ece615/attachment-0001.html>