Re: Can't verify signature created w/ .NET
On Fri, Aug 27, 2010 at 6:49 AM, Scott Cantor canto...@osu.edu wrote: Any help or tips would be *much* appreciated. First tip is that posting signed XML in email won't help with debugging it, it's already trashed at that point. Every character of whitespace matters. OK. That might be hard to come by since the federation server is writing them out to its logs in who knows what manner. I can serialize the XML to a file on my end no problem, but not sure about how to go about this on the server side. If I succeed, I'll post them here as attachments ;-) The general answer is that you need to obtain the digested octets on *both* ends to compare them. You may find this helpful: https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManSigErrors This link is really useful. Either the signer is buggy or you've corrupted the XML in transit, but the only way to know is to compare the bits after c14n. Thanks for the advice, Scott. I'll give this another shot and post back here if I get stuck. -- Regards, Travis Spencer
RE: Can't verify signature created w/ .NET
Any help or tips would be *much* appreciated. First tip is that posting signed XML in email won't help with debugging it, it's already trashed at that point. Every character of whitespace matters. The general answer is that you need to obtain the digested octets on *both* ends to compare them. You may find this helpful: https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManSigErrors Either the signer is buggy or you've corrupted the XML in transit, but the only way to know is to compare the bits after c14n. -- Scott
Can't verify signature created w/ .NET
Hi All, I am trying to send my federation server a SAML message that has a signed assertion in it that I have created using .NET 3.5. My federation server is written in Java and uses the latest version of Apache XML Security to process these messages' digital signatures. After an embarrassingly long time of sifting through code, blog posts, mailing lists, and the W3C's spec, I am stuck and would *greatly* appreciate some help. When I use the federation server to create a SAML message and send it back to it for verification, it accepts the signature. In this use case, effectively, it's a signature produced by your toolkit being validated by it. I have have made the assertion created by my .NET code very close to the one accepted by the federation server (differences described after the XML docs). However, the XML signature processor in the server still considers it invalid. I've added the public key in the SAML message to the cacerts file used by the JRE that my federation server runs in (in case that makes a diff). Here are the documents that I'm working w/. The first is produced by the federation server and is signed w/ your toolkit which is being validated OK: samlp:Response IssueInstant=2010-08-20T20:03:19.135Z ID=gzkD2IIbWdVCDYURBGADixzaWNB Version=2.0 xmlns:samlp=urn:oasis:names:tc:SAML:2.0:protocol saml:Issuer xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertionlocalhost:default:entityId/saml:Issuer samlp:Status samlp:StatusCode Value=urn:oasis:names:tc:SAML:2.0:status:Success/ /samlp:Status saml:Assertion Version=2.0 IssueInstant=2010-08-20T20:03:19.140Z ID=i4JxuzpsMFt59B4m0THfGZFamo7 xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertion saml:Issuerlocalhost:default:entityId/saml:Issuer ds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#; ds:SignedInfo ds:CanonicalizationMethod Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#/ ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1/ ds:Reference URI=#i4JxuzpsMFt59B4m0THfGZFamo7 ds:Transforms ds:Transform Algorithm=http://www.w3.org/2000/09/xmldsig#enveloped-signature/ ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#/ /ds:Transforms ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/ ds:DigestValue6sws+aEYHaQnUtS41TlGkoLvPMc=/ds:DigestValue /ds:Reference /ds:SignedInfo ds:SignatureValueWMQW5cNDoxPbkM/YA+5KOLpHqrhY3M2ir9BtooTrmgAVzGR+0qDTNq1 0knR36mQmJMV0PKiLb8wL /EOetUx8Y8SkruVb5qcv0J2rWkXJbo68uR/2ilB5BYnnNVxkV0OzzdEjnmPLFyTNoraOaZ4GR8Du oGA+0cp43Q55tCaBLYS/qIxoiQrpw+XVHUy+Xh3BMwYj0CoaNCZmEE06iVWb0Fd7VY4j4VOcuRq3 ImQ27MOmUQvwk1lVH4y+OMiHt9SijCWP1Q2TzUGk5jvtlXc60sA56cD3uHb54tEAlmK3ciB7nkpZ ZlCbPUipPICYrQkl94uHt0M224nMXfv8++aB0Q==/ds:SignatureValue ds:KeyInfo ds:X509Data ds:X509CertificateMIIC/jCCAeagAwIBAgIQFbo2Qg0w955Dgf1MzdFm6zANBgkqhk iG9w0BAQUFADARMQ8wDQYDVQQD EwZUcmF2aXMwIBcNMTAwNTAxMDYxODQ3WhgPMjExMDA0MDcwNjE4NDdaMBExDzANBgNVBAMTBlRy YXZpczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMYhy0zAuKLqF1Qnz89o+7DvfE8y OTAspkNw7GInKnKl5SgJ0OGvpJehU4neEYiPjL7nfHGq4kGL+u/735gRBlMjQWsdCQAPZUR4OJbQ zmcNGRIeZ5yUtduCjToI/ASXmUVHUK5sMwSvoSZoTMTsVrTe+oxtKIplq2WvdvrHVed0xIMGqk/u fi82cNEebE61aXQczpICrgMavnaTgQ2xzM6hu2lxL9C0SdNE9QOqtW+JzHQRYy2mzGkxsByuZ/M9 8MVkKJSQt24sYy52WK7MvlNnY8PSuPvdl8E1OWPfmCJNdXcYLTVZu399BNZazrVDPzybUbnnwygE g/hboHnGTNMCAwEAAaNQME4wFQYDVR0lBA4wDAYKKwYBBAGCNwoDBDAqBgNVHREEIzAhoB8GCisG AQQBgjcUAgOgEQwPVHJhdmlzQGRvZ3dvb2QAMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEFBQADggEB AJplSd5TXGT3jvX7aK3C+pohVRl/VfyigGFGU/AvX+oiqy+dCy4pw7Ee/luDkHCfReWG1aEIS3w7 cSf8fHKsS5e339V4HsMVY7YaFyyQV7xzEuCMnDIIClcexF6Bm4LZQXcvojrYdnt0gedrmXi450N+ YA5k/qGkMz4EFKv4rdxJxT2NVc6Lrv+ZfZJU0yHz74krbuG1I181+MtcKwfmKIzjU+HZ6PrwJktH 2XO6rEP/yDg6gKSokJyi7OLpbVoKVN1obYmeB0PbAQChvEhCDNrbDMOkEEnhYlta6sdMLvIqbfRF vqjKGEqpMTEetijll70vEduJD9zsL6VRusIJ/pI=/ds:X509Certificate /ds:X509Data ds:KeyValue ds:RSAKeyValue ds:ModulusxiHLTMC4ouoXVCfPz2j7sO98TzI5MCymQ3DsYicqcqXlKAnQ4a+kl6FT id4RiI+Mvud8cariQYv6 7/vfmBEGUyNBax0JAA9lRHg4ltDOZw0ZEh5nnJS124KNOgj8BJeZRUdQrmwzBK+hJmhMxOxWtN76 jG0oimWrZa92+sdV53TEgwaqT+5+LzZw0R5sTrVpdBzOkgKuAxq+dpOBDbHMzqG7aXEv0LRJ00T1 A6q1b4nMdBFjLabMaTGwHK5n8z3wxWQolJC3bixjLnZYrsy+U2djw9K4+92XwTU5Y9+YIk11dxgt NVm7f30E1lrOtUM/PJtRuefDKASD+FugecZM0w==/ds:Modulus ds:ExponentAQAB/ds:Exponent /ds:RSAKeyValue /ds:KeyValue /ds:KeyInfo /ds:Signature saml:Subject saml:NameID Format=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedjoe/saml:NameID saml:SubjectConfirmation
