<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/30/17 4:35 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D2359E56-AA0F-4259-8ECF-47F3B1F5494F@osu.edu">
<pre wrap="">
</pre>
<pre wrap="">
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</pre>
</blockquote>
<br>
Ah! I forgot about the URL encoding.<br>
<br>
<blockquote type="cite"
cite="mid:D2359E56-AA0F-4259-8ECF-47F3B1F5494F@osu.edu">
<pre wrap="">
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.</pre>
</blockquote>
<br>
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. :-)<br>
<br>
<blockquote type="cite"
cite="mid:D2359E56-AA0F-4259-8ECF-47F3B1F5494F@osu.edu">
<pre wrap="">
So, either the log itself is not an accurate reflection, or the request to the server is already corrupt by then.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
</body>
</html>