Troubleshooting the "Unable to decode" (IdP 3.3)

[Brent Putman]

On 8/30/17 5:57 PM, O'Dowd, Josh wrote:
> Thanks Scott,
>
>
>> I think it's pretty likely that something out there is accessing a URL on this server that's perhaps improperly being stuck behind the SP and is triggering a redirect that the "something" is handling badly and corrupting before following it to the IdP and then it plays a corrupt request. I don't think there's much beyond that that's knowable, but perhaps getting the user agent from a log entry would be interesting.
> Well this leads me back to the other really "odd" component in this issue, that the ${idp.remote_addr} is coming in from a subnet (173.252.95.x) that is registered to Facebook, though the "issuer" in the SAMLRequest is definitely one of our local SPs.  I am still trying to get some clarity on why that is, from our sysadmin group, but I am getting crickets instead.  I no longer suspect Facebook is involved, here but all the requests coming in from our other local SPs are from our internal IP ranges.

That is pretty consistent with Scott's comments then.  Quite possibly
some automated thingy/widget/bot/whatever at Facebook is issuing a
request to a resource protected by that SP.  The Facebook thingy is
getting back the  redirect from the SP, and in trying to play the role
of the browser-compliant HTTP user agent, it's corrupting the request
somehow and issuing it to the IdP.   That or something similar is
probably what's going on.

Or if it's not that, then it's probably something on the network
between the client HTTP user agent and the IdP that's molesting and
corrupting the request , like your LB, or some mysterious security
blackbox (IDS, application firewall, etc) or similar.

As Scott says, the User Agent from the Apache log would be very
interesting.  If you can get your network/security guys to help you
trace the full logical path of the request into the IdP from the point
that it hits your border network device, that would also be interesting.

Not sure we can tell you much more than that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170830/1ab9347b/attachment.html>