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

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



Hi Sampo,
   I've been digging more deeply into the XML digest issue, and it seems
there is one issue in the zxid side.  The "xsi:xsi:type" issue appears to be
injected by zxid, as the original message has types correctly declared like:

<saml:AttributeStatement
xmlns:xs="http://www.w3.org/2001/XMLSchema";><saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="Email
Address"><saml:AttributeValue *xsi:type="xs:string" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"*>demo@localhost
</saml:AttributeValue></saml:Attribute>
...
</saml:AttributeStatement>

The attribute declaration I noted in my last e-mail was extracted from the
zxid blob log line, not the original XML.  Further study revealed that the
original XML was correctly formed.

   So, when manually correcting this issue in the XML, I now get the
expected base64 digest as declared in the original PingFederate
SAMLResponse. I compared the result using the following perl scripts to
validate the message:

# calculate digest of canon blob reported in zxid log
perl -MDigest::SHA1 -MMIME::Base64 -e '$s=q{...}; $d=Digest::SHA1::sha1($s);
warn encode_base64($d);'

# independently calculate digest (XML::CanonicalizeXML uses libxml2 to
calculate  the canonical representation)
perl -MXML::CanonicalizeXML -MDigest::SHA1 -MMIME::Base64 -e '$xpath =
q{<XPath>(//. | //@* | //namespace::*)</XPath>}; $xml=q{...};
$s=XML::CanonicalizeXML::canonicalize( $xml, $xpath, [], 1, 0 );
$d=Digest::SHA1::sha1($s); warn $s; warn encode_base64($d);'

   From a cursory study, it appears the issue may be related to namespace
parsing in function TXDEC_ELNAME (dec-templ.c).  Perhaps you could provide
some insight here?  I could send a complete SAMLResponse if you wish to use
it for debugging purposes.

Regards,
Eric


On Sun, Aug 23, 2009 at 9:23 PM, Eric Rybski <rybskej@xxxxxxxxx> wrote:

> Sampo,
> The digest I independently calculated did match ZXID.  So there must be
> something different in the XML they are using to calculate the digest.
> I did see a few XML parsing errors in the zxid log, like:
> t    zxlib.c:836 zx_dec_unknown_attr zx d Known attribute(xsi:type)
> tok(147) in wrong context(292)
> t    zxlib.c:836 zx_dec_unknown_attr zx d Known attribute(xsi:type)
> tok(147) in wrong context(292)
> t    zxlib.c:836 zx_dec_unknown_attr zx d Known attribute(xsi:type)
> tok(147) in wrong context(292)
> t    zxlib.c:836 zx_dec_unknown_attr zx d Known attribute(xsi:type)
> tok(147) in wrong context(292)
>
> These appeared to have been triggered by elements from the test LDAP server
> (serving the SAML IdP), which looked like the following:
> <saml:Attribute Name="Email Address"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml:AttributeValue
> xsi:xsi:type="xs:string">demo@localhost
> </saml:AttributeValue></saml:Attribute>
>
> Note the odd (malformed?) attribute: xsi:xsi:type="xs:string"
>
> I tried using libxml2 to canonicalize the original XML, and got invalid
> attribute and namespace warnings on those attributes.  I've put in a support
> request to Ping for this.
>
> -Eric
>
> On Sun, Aug 23, 2009 at 9:00 AM, <sampo@xxxxxxxxxxx> wrote:
>
>> Eric Rybski wrote:
>> > Sampo,
>> >     1. Below is my current zxid.conf.  I did not change the default
>> value
>> > for WANT_SSO_A7N_SIGNED.
>> >
>> > URL=https://localhost/zxidhlo.pl
>> > NICE_NAME=Test 1
>> > NOSIG_FATAL=0
>> > NAMEID_ENC=0
>> > MD_FETCH=0
>> > MD_POPULATE_CACHE=0
>> >
>> > 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.
>>
>> Cheers,
>> --Sampo
>>
>> > 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