Troubleshooting the "Unable to decode" (IdP 3.3)

[O'Dowd, Josh]

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.

> Well, that rules out "all requests from it fail" or you'd probably know about it

That's just it, we aren't getting any service complaints, just a bunch of errors on the IdP, and YES, ALL of the requests are coming from those external odd IP addresses.  I confirmed that our idp-audit logs show no attribute releases to those IPs.

> Being that it's local I suppose you can get them to stop signing since there's no reason to be.

The local SP admins for these particular services are in the process of replacing the SP servers in the coming months, and they are removing Apache/Shibd and switching authn to CAS protocol requests from the  webapps(not worth explaining here), so much of this will be moot in the near future.  I am still happy to see if they will stop signing SAML requests.

Josh