[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:
> 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.

I've been so busy adding IdP and ID-WSF features that I have not had
time to resolve this. However it is not forgotten.

> 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.

Sorry about that. ZXID is still 0.x for a reason. Which functions would
you like to see reinstantiated?

> 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.

Not yet addressed.

Cheers,
--Sampo

> 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