[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working with PingFederate (Was: Re: zxid and shared/distributed filesystems?)



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