[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,
>    Attached is a sample SAMLResponse that is triggering the canon issue.
>  zxid XML canon parser is altering the "xmlns:xsi" attribute during
> parsing,
> truncating and concatenating it with the xsi:type attribute.  It looks
> like
> the digest would calculate correctly otherwise.
>
> Let me know if I can provide further information.

THanks for the test material. I am entering a horribly busy week, but I'll
try to look into this as it seems a real bug in my XML parsing code.

Cheers,
--Sampo

> Thanks,
> Eric
>
> On Mon, Aug 24, 2009 at 1:30 PM, <sampo@xxxxxxxxxxx> wrote:
>
>> Eric Rybski wrote:
>> > 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.
>>
>> Please do. That would be very helpful.
>>
>> Cheers,
>> --Sampo
>>
>> > 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