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