Customer's PingFederate SSO Appears Nonconformant

Question

My customer has a ping federate installation and it appears to be producing incompatible authentication response documents. The document is well-formed and does not contain illegal characters.

The big problem is that the document's nodes do not contain "ds:" in the node names. This is unfortunate as my authentication library (omniauth-saml) looks for ds names exclusively when validating.

Is the library at fault? Is the Ping Federate SAML document at fault? I have started to patch the matchers to use XPath's "contains" helper but even then the document's digests and certificate do not calculate to the correct values.

1. Is the library at fault?
2. Is the Ping Federate SAML document at fault?
3. Should the Ping Federate document, when canonicalized, still verify?

Here's a sample of their SAML response

<samlp:Response Destination="http://a/dest" IssueInstant="2012-07-12T18:21:28.011Z" ID="a.valid.rand.id" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://their/issuer</saml:Issuer>
  <Signature>
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <Reference URI="#vZZQnHjOx1.u8c3uupdxDb_cmRu">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <DigestValue>some_digest_value</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>some_signature_value</SignatureValue>
    <KeyInfo>
      <X509Data>
        <X509Certificate>their_well_formed_x509_cert</X509Certificate>
      </X509Data>
      <KeyValue>
        <RSAKeyValue>
          <Modulus>a_modulus</Modulus>
          <Exponent>AQAB</Exponent>
        </RSAKeyValue>
      </KeyValue>
    </KeyInfo>
  </Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion Version="2.0" IssueInstant="2012-07-12T18:21:28.058Z" ID="SOME_ID">
    <saml:Issuer>http://their/issuer</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">14096079</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2012-07-12T18:26:28.058Z" Recipient="http://link/back/to/me"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotOnOrAfter="2012-07-12T18:26:28.058Z" NotBefore="2012-07-12T18:16:28.058Z">
      <saml:AudienceRestriction>
        <saml:Audience>http://an/audience/restriction</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2012-07-12T18:21:28.058Z" SessionIndex="SOME_ID">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="uid">
        <saml:AttributeValue xsi:type="xs:string">a_uid</saml:AttributeValue>
      </saml:Attribute>
      <!-- removed all the other attributes -->
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Answer 1

Making this a more official answer...

I think your interpretation of that line of code may not be correct. I believe it is doing the lookup based on the dsig schema (http://w3.org/2000/09/xmldsig#), not assuming the prefix is "ds". See: http://www.germane-software.com/software/rexml_doc/classes/REXML/XPath.html

Your issues may have more to do with how your libraries are handling the CanonicalizationMethod (http://www.w3.org/2001/10/xml-exc-c14n#) if the signature validation is failing.

Again - hundreds of "off the shelf" SAML products are interoperable with PingFederate. I'd be surprised if your issue is the result of something that PingFederate has misinterpreted from the SAML 2.0 spec.