[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working with PingFederate (Was: Re: zxid and shared/distributed filesystems?)

Eric Rybski wrote:
> Sampo,
>     1. Below is my current zxid.conf.  I did not change the default value
> URL=https://localhost/zxidhlo.pl
> NICE_NAME=Test 1
> I dug deeply into PingFederate configuration for my SP endpoint, and found
> a
> Signature Policy property "Always sign the SAML Assertion" which I have
> now
> enabled.  Not sure why it wasn't already enabled when importing my
> metadata,
> but at least now I'm getting a signature.
> Unfortunately, it looks like I'm still not in the clear.  I'm now getting
> a
> digest check error:
> t    zxsig.c:222 zxsig_validate   zx E Message
> digest(lYrwi9YBLpLU7ZVVyZ2+mIWLka0=) mismatch at
> sref(#sVce0k5jDJfLg4He6AoG9b.LXKz), canon blob(...)
> t  zxidsso.c:318 zxid_sigres_map   zx E Bad digest. Canon problem? 3
>    Is there a way I can review the zxid calculated digest, for comparison?
>  It's not included in the log message.  I've contacted Ping on this issue,

The canon blob() has what went into message digest, e.g. sha1. If
you can get ping to print to the log what they put into the digest
when creating the signature, you can spot the difference.

Once the difference in canonicalization is found, we can start
arguing about whose canonicalization is correct. Some of the
things that typically wreck havoc are convoluted use of XML
namespaces and namespace prefixes, failure to include namespaces
that are actually used (this is actually easy to check: paste
the canon blob to some xml validator and see if it is missing
namespaces), and superflous whitespace, line endings, etc.
I recommend simply omitting all whitespace you can as that increases
the probability of interoperation significantly.

> as I've tried to independently calculate the digest of the canonical XML
> in
> Perl, using the reported the blob(...) value, and I also don't match the
> PingFederate SAML response digest.  (So I'm assuming this is a PF issue at
> the moment.)

Did the digest match what ZXID calculated?

XML canonicalization is one of the biggest sources of bugs in
various XML-DSIG implementations. Unfortunately this affects
SAML interoperability in quite big way.


> 2.  The SSOCircle IdP metadata is available at:
> http://idp.ssocircle.com/idp-meta.xml
> Regards,
> Eric
> On Sat, Aug 22, 2009 at 9:07 AM, <sampo@xxxxxxxxxxx> wrote:
>> Eric Rybski wrote:
>> >    I'm having an issue getting digital signature validation
>> > working with a PingFederate IdP instance.  The PF IdP metadata (cached
>> in
>> > my
>> > cot/) includes a certificate, the POST SAMLResponse contains a
>> signature,
>> > and I have the IdP CA cert in my /var/zxid/pem/ca.pem. But I keep
>> getting
>> > errors like:
>> >
>> > t  zxidsso.c:559 zxid_sp_sso_finalize zx E SSO warn: assertion not
>> signed.
>> > Sigval((null)) (nil)
>> Checked your attachments. The assertion really is not signed.
>> The SAML spec is unambiguous: if in metadata
>> SPSSODescriptor/@WantAssertionsSigned is true, then
>> the IdP MUST sign the Assertion.
>> I ship ZXID with WANT_SSO_A7N_SIGNED=1, so unless you have changed
>> this setting, it would appear that PingFederate is not honouring
>> this part of the metadata.
>> Please check this.
>> > I've currently worked around this by setting "NOSIG_FATAL=0" in the
>> > zxid.conf, but this isn't a long-term solution.
>> > Overall, other than the above mentioned issues, the library is
>> > working OK so far with a PingFederate IdP and perfectly with
>> > ssocircle.com.
>> I once had a thread about shipping the ssocircle IdP metadata
>> with ZXID, but somehow it never happened. Can you share
>> the ssocircle metadata with me (or the list)?
>> Cheers,
>> --Sampo
>> > Thanks,
>> > Eric