Troubleshooting the "Unable to decode" (IdP 3.3)
O'Dowd, Josh
Josh.O'Dowd at mso.umt.edu
Wed Aug 30 17:20:01 EDT 2017
> 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.
Is there anything I can do to debug from the SP side of things. Looking at the SAMLRequest(once decoded), I can see that the issuer is one of our local SPs(which, as you already know is a Shibboleth SP)?
Josh
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, August 30, 2017 3:10 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Troubleshooting the "Unable to decode" (IdP 3.3)
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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list