Topic
2 replies Latest Post - ‏2013-01-22T19:57:20Z by jaluecht
jaluecht
jaluecht
21 Posts
ACCEPTED ANSWER

Pinned topic Signature verification

‏2013-01-22T19:00:46Z |
I am attempting to verify the following signature header in DataPower. I have the verify action set to verify ALL Signatures and reference the verifying cert via the 'name:cryptocert' method.

From soapUI I am receiving a 'Incorrect reference digest value' error. Can anyone tell from the following header why it might be failing?

Thanks in advance

<SAML>
<saml:Assertion Version="2.0" ID="_7a9c7379-3d99-4a15-8684-3959ddf08412" IssueInstant="2012-10-01T20:39:14Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idrstreasury.uhc.com</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<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="#_7a9c7379-3d99-4a15-8684-3959ddf08412">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="#default code ds kind rw saml samlp typens" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>AFjXdVrM9nR8e1HPQhXLzATTMpI=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>N2Z2jgZ1+UxM215bhHXabylnYYzIFzZknfEnIRIOVw4xIMa6gDO1fZPtSqHozCB/ExpIyCNcUj528sh7XVK/5BG+3cI+GmtryIqTReYJGYdLHPcepVDHBz5N8SX4ZgT2c7ciZIB8/LQOx54U85tD1aPJFltkOlbhr5UmVghTIRU=</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIEmzCCBASgAwIBAgIQFeIv93r+ZY0s3+TIjv2R3DANBgkqhkiG9w0BAQUFADCBujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVyaVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2VydmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMgSW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0wOTA2MDIwMDAwMDBaFw0xMDA2MDIyMzU5NTlaMIGfMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEQMA4GA1UEBxQHQ3lwcmVzczEbMBkGA1UEChQSVW5pdGVkSGVhbHRoIEdyb3VwMScwJQYDVQQLFB5VSEcgSVQgRW50ZXJwcmlzZSBUZWNoIFByYWN0aWMxIzAhBgNVBAMUGlRyZWFzdXJ5Q2hlY2tTdGFnZS51aGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCXnNk0OSC9urukd728i9xKvc7fltR6vdS3uua9LAGnzBwaueOCz6IESYJDKi/JeeJdo1iSRKPc49jrpaeMHkZdqu+JF79dDiz8M24LQeB6GRBVWf7RbolJyNGUd19G6dFX9bMT+WoQls8i9etYQO0/na5RcYteJZcsliL+9bkvHQIDAQABo4IBuTCCAbUwCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL1NWUkludGwtY3JsLnZlcmlzaWduLmNvbS9TVlJJbnRsLmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0lBC0wKwYJYIZIAYb4QgQBBgorBgEEAYI3CgMDBggrBgEFBQcDAQYIKwYBBQUHAwIwcQYIKwYBBQUHAQEEZTBjMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wOwYIKwYBBQUHMAKGL2h0dHA6Ly9TVlJJbnRsLWFpYS52ZXJpc2lnbi5jb20vU1ZSSW50bC1haWEuY2VyMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjANBgkqhkiG9w0BAQUFAAOBgQCNrvJQeg+cj37xp29V5zO+xO9bF8DsRfj1rCuajdk2JX5OYF+1tZ0KOjNyXlUESvDHB2BFnOrARXHgaskDF29hS+yR1kBHkAjm92Jj5njnNoxo3/9fYvtgzDBj08OdJ0byA4/EzFdnWTKiIFdz3InkabinWuVj6p5VRr6h+vbTkQ==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">https://idrstreasury.uhc.com/treasurycheckfree</saml:NameID>
</saml:Subject>
<saml:AuthnStatement AuthnInstant="2012-10-01T20:39:14Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="ApplicationID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue>uhg#</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<saml:AttributeStatement>
<saml:Attribute Name="ApplicationPwd" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue>g0PaCk7e</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<saml:AttributeStatement>
<saml:Attribute Name="UserDomainID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue>atata</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</SAML>
Updated on 2013-01-22T19:57:20Z at 2013-01-22T19:57:20Z by jaluecht
  • swlinn
    swlinn
    1327 Posts
    ACCEPTED ANSWER

    Re: Signature verification

    ‏2013-01-22T19:07:37Z  in response to jaluecht
    Typically this means that the document has changed.
    The private key associated with the X.509 certificate encrypts a hash of the document,
    and the verification will decrypt that hash with the certificate and compare that to
    the hash that it calculates itself. If they don't match, the verification fails. The
    hash includes whitespace, so reformatting the xml will still cause this type of error.

    Regards,
    Steve
  • jaluecht
    jaluecht
    21 Posts
    ACCEPTED ANSWER

    Re: Signature verification

    ‏2013-01-22T19:57:20Z  in response to jaluecht
    Actually - I think I found out why from my end it was initially failing. Initially it was failing with not being able to find a signature.

    From a high level, the structure of the header originally is
    <AuthenticationHeader>
    <SAML>
    <saml:Assertion>
    ....
    <Signature>...</Signature>
    </saml:Assertion>
    </SAML>
    </AuthenticationHeader>

    When the client sends a request, the probe displays ALL content between <SAML></SAML> as text displayed by the color black. There is now XML formating.

    The text contains all XML nodes, but it is not formatted as something the probe views as XML structure.

    If I cut and paste the same request into a soapUI project and submit, the formatting is as expected.

    It is almost as if the client code used to create the request takes the <SAML> content and streams it in the request encoded in such a way that it ends up being test.

    Has anyone experienced anything similar?