[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,

   Hadn't heard from you on this topic in a while, regarding the loss of
attributes (modification of input message) during XML canonicalization for
message validation.

Due to backwards incompatibility of zxid 0.33 and later with 0.32 (functions
for ldif parsing which I depend on were deprecated and removed without
warning), I've not had the time yet to integrate later releases into my
environment to validate this.

Can you confirm whether this issue was addressed in any of the more recent
releases?  Ideally, I'd like to generate a patch for 0.32 for now, then
upgrade later when time and resources permit.

Thanks,
Eric

On Sun, Oct 11, 2009 at 11:56 PM, Eric Rybski <rybskej@xxxxxxxxx> wrote:

> Hi Sampo,
>
>    Have you had a chance to look into this issue?  I've not had much luck
> tracing it down myself.  Also, the diff of zxid 0.32 to 0.33 was so large
> that I couldn't determine whether 0.33 addresses this issue.  (My
> integration is tightly coupled with 0.32, so I'd need a compelling reason to
> upgrade to test.)
>
> Thanks,
> Eric
>
> On Mon, Aug 31, 2009 at 8:09 PM, <sampo@xxxxxxxxxxx> wrote:
>
>> 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