Troubleshooting the "Unable to decode" (IdP 3.3)

[Cantor, Scott]

On 8/30/17, 4:30 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

> I saw the same Zip package error when I used that request direct to the IdP with my browser.  So I can confirm the Sample
> request I provided in the earlier post is not valid.

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

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.

So, either the log itself is not an accurate reflection, or the request to the server is already corrupt by then. But it's not what the SP actually would have sent.

That doesn't explain it, but it does add context.

The reason the lack of a URL encoding step is blowing things up is that the + characters get decoded into spaces before we feed it into the base64 decode and then to INFLATE.

-- Scott