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