Troubleshooting the "Unable to decode" (IdP 3.3)

[O'Dowd, Josh]

Thanks Brent, Scott,

I’ll see what I can do to get HTTP User Agent info, but I’ll have to pick this back up tomorrow.  Thanks again.  You guys are awesome, as always.

Josh

From: Brent Putman [mailto:putmanb at georgetown.edu]
Sent: Wednesday, August 30, 2017 4:09 PM
To: Shib Users <users at shibboleth.net>; O'Dowd, Josh <Josh.O'Dowd at mso.umt.edu>
Subject: Re: Troubleshooting the "Unable to decode" (IdP 3.3)




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/7ac50dd0/attachment-0001.html>