Troubleshooting the "Unable to decode" (IdP 3.3)
Cantor, Scott
cantor.2 at osu.edu
Wed Aug 30 17:10:12 EDT 2017
On 8/30/17, 4:59 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:
> Yes according to our sysadmin we are running requests thru a Kimp Hardware LB to one of two IdP nodes that each have an on
>-board apache handling SSL. For the record, I don’t like that setup and I know that you guys recommend no Apache
> impedance. Again, the sample request we are currently debugging came from the httpd-access log of one of the IdP node
> servers.
Apache doesn't really log nonsense, so it was corrupted by then in both the ways I identified. Could be that the improper encoding of the SAMLRequest caused the Signature parameter to be dropped, hard to say. Either way, it was broken on entry.
You could set up an SP and have it sign requests and I suppose see if that alone is enough to trigger it to fail, which might point to something. Signing requests is rare enough that it's not impossible you just haven't seen this before.
-- Scott
More information about the users
mailing list