Directory Programming .NET

Hi,
I am getting a signature verification failure while deploying ADFS.
Does anyone have an idea to fix that issue?
Thank you very much in advance.

Nathan

ADFS logs :
-------------------------------------------------------------------------------------------------------
2008-06-20T07:45:55 [VERBOSE] Processing HTTP GET: https://srvgrnum2.myorg.local/adfs/ls/?wa=wsignin1.0&wreply=https://sharepoint.myorg.local:8443/claimapp&wct=2008-06-20T07:45:56Z&wctx=https://sharepoint.myorg.local:8443/claimapp
2008-06-20T07:45:55 [VERBOSE] Received SignIn Request.
2008-06-20T07:45:55 [VERBOSE] HOMEREALM: Realm = urn:federation:myorg2, Source = Implied
2008-06-20T07:45:55 [INFO] Received signin request via query string.
2008-06-20T07:45:55 [VERBOSE] Sign In Request Dump
--------------------
wreply   = https://sharepoint.myorg.local:8443/claimapp
wtrealm  =
whr      =
wauth    =
wcontext = https://sharepoint.myorg.local:8443/claimapp
wct      = 2008-06-20T07:45:56Z
ttpindex = 0
--------------------
2008-06-20T07:45:55 [INFO] Redirecting to account realm OpenSSO IdP (https://myorg2-sso.myorg2.com:443/opensso/WSFederationServlet/metaAlias/myorg2).
2008-06-20T07:45:55 [VERBOSE] SignIn Request Dump:
System.Web.Security.SingleSignOn.SignInRequest
2008-06-20T07:45:55 [INFO] Processing HTTP POST: https://srvgrnum2.myorg.local/adfs/ls/
2008-06-20T07:45:55 [VERBOSE] Received SignIn Response.
2008-06-20T07:45:55 [VERBOSE] HOMEREALM: Realm = urn:federation:myorg2, Source = Implied
2008-06-20T07:45:55 [INFO] Received signin response via post body.
[VERBOSE] Sign In Response Dump
--------------------
wcontext = https://sharepoint.myorg.local:8443/claimapp\https://sharepoint.myorg.local:8443/claimapp
wresult to follow
XML Data Follows
----------------
<wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
  <wst:RequestedSecurityToken>
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="s355f067eb5797cff94a040422913ad73e99766a001" Issuer="urn:federation:myorg2" IssueInstant="2008-06-20T07:45:56Z">
<saml:Conditions NotBefore="2008-06-20T07:35:56Z" NotOnOrAfter="2008-06-20T07:55:56Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>urn:federation:myorg</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AuthenticationStatement AuthenticationMethod="urn:com:sun:identity:KERBEROS" AuthenticationInstant="2008-06-20T07:45:56Z">
<saml:Subject>
<saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/UPN">njavega@null</saml:NameIdentifier>
</saml:Subject>
</saml:AuthenticationStatement>
<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="#s355f067eb5797cff94a040422913ad73e99766a001">

<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>2QyWEyJ+Ja287iANe7UJwqOTgQc=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>

fDjjGcOBlPCOxclfZoIpEwGvjmENd56R30HKG8v/M8WqeM/OJhIZjI5lXXKRoZ+zBEjlCr84bYre

atyRLljMS1OK6LMr4sjG1q9U3YvvboOrFNURMABQHo1Hoi6m7FRKihLUSfq3f1PrWjrsjTuCYIna

uIK3QVbDOojkFklEdNM=

</SignatureValue>

<KeyInfo>

<X509Data>

<X509Certificate>

MIIFNDCCBBygAwIBAgIQCZCS4JVRqhTx99Nd+R17TzANBgkqhkiG9w0BAQUFADCBlzELMAkGA1UE

BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl

IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAd

BgNVBAMTFlVUTi1VU0VSRmlyc3QtSGFyZHdhcmUwHhcNMDcxMjAzMDAwMDAwWhcNMTMwMTA3MjM1

OTU5WjCBxzELMAkGA1UEBhMCRlIxDzANBgNVBAgTBkZyYW5jZTETMBEGA1UEBxMKTW9udGJvbm5v

dDESMBAGA1UEChMJQ2FwZ2VtaW5pMQ4wDAYDVQQLEwVBTUdTUzEvMC0GA1UECxMmSXNzdWVkIHRo

cm91Z2ggQ2FwZ2VtaW5pIEUtUEtJIE1hbmFnZXIxIzAhBgNVBAsTGkNvbW9kbyBQcmVtaXVtU1NM

IFdpbGRjYXJkMRgwFgYDVQQDFA8qLmNhcGdlbWluaS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A

MIGJAoGBAIdxajX7Gc2ez7JRgTLErhY6Pg7GF4Rtb75Z8QKJrZSzhPhfR4+/76fapg848newTcHo

5zTWeHS2wNTfYzEfMUVKQVRRotHw9tDIvsg8yAdFMv70dYhGWrhruyy5zc0WU0uQRjgwVYeBpAqg

tppPL7JMChSik9OvqhIuKVm+5/VzAgMBAAGjggHMMIIByDAfBgNVHSMEGDAWgBShcl8mGyiYQ5Vd

BzfVhZadS9LDRTAdBgNVHQ4EFgQUmQSiMByhVCZ1/uYvPMJ0MxQ4sEwwDgYDVR0PAQH/BAQDAgWg

MAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBEGCWCGSAGG+EIB

AQQEAwIGwDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBDArMCkGCCsGAQUFBwIBFh1odHRwczov

L3NlY3VyZS5jb21vZG8ubmV0L0NQUzB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9k

b2NhLmNvbS9VVE4tVVNFUkZpcnN0LUhhcmR3YXJlLmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21v

ZG8ubmV0L1VUTi1VU0VSRmlyc3QtSGFyZHdhcmUuY3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEF

BQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQWRkVHJ1c3RTZXJ2ZXJDQS5jcnQwJAYI

KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAHi85

B+4U64sZQyeAjMpl9X+6/I4APwXpQi1u45YcvW1j7olmWSHTdItxa94q0CtTNNxB7aUQmTEznTtD

ct68r7la5fN4oLM3EoFJGx9CO9ZVak/HqfUkCq+Ba5zgRCtGNfMltAsn2UH11OilaFeEDwa8Nvqr

J+TfEhiUPVTOkt+b3I8dI827h5RF9qIv4k7f2iwfCTj2ae1P/K9FybSlB8ggbmo8HkuE/1QYUek6

DWGByvhTSBBPbdNfOR/nG0srEogtOsnuvQ+qtFptys3r6I1L7qx2dJez5Ji8xzZoGQtE1mJ6XD3N

2nV5HyXod26p5ADq+FTg1fM1egf10x5EAw==

</X509Certificate>

</X509Data>

</KeyInfo>

</Signature></saml:Assertion>
</wst:RequestedSecurityToken>
  <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <wsa:Address>urn:federation:myorg</wsa:Address>
    </wsa:EndpointReference>
  </wsp:AppliesTo>
</wst:RequestSecurityTokenResponse>
----------------
2008-06-20T07:45:55 [INFO] Requesting token for https://sharepoint.myorg.local:8443/claimapp from FS using inbound token.
2008-06-20T07:45:55 [VERBOSE] Parse: Token NOT found in cache
2008-06-20T07:45:55 [VERBOSE] SAML: effectivetime = 06/20/2008 07:35:56
expirationtime = 06/20/2008 07:55:56
2008-06-20T07:45:55 [VERBOSE] Verifying Cert Thumbprint - E0A202F81902FE87C9392DF4659E22BCC4D1ED63
2008-06-20T07:45:55 [VERBOSE] Verifying Key Exponent - 3
2008-06-20T07:45:55 [VERBOSE] 010001
2008-06-20T07:45:55 [VERBOSE] Verifying Key Modulus - 128
2008-06-20T07:45:55 [VERBOSE] 87716A35FB19CD9ECFB2518132C4AE163A3E0EC617846D6FBE59F10289AD94B384F85F478FBFEFA7DAA60F38F277B04DC1E8E734D67874B6C0D4DF63311F31454A415451A2D1F0F6D0C8BEC83CC8074532FEF47588465AB86BBB2CB9CDCD16534B90463830558781A40AA0B69A4F2FB24C0A14A293D3AFAA122E2959BEE7F573
2008-06-20T07:45:55 [WARNING] Failing signature verification because SignedXml::CheckSignature returned false.
2008-06-20T07:45:55 [WARNING] SAML token signature was not valid: AssertionID = s355f067eb5797cff94a040422913ad73e99766a001
2008-06-20T07:45:55 [VERBOSE] Processing FS response: policy version is a375fe8c-f488-4f9b-84fd-ca7be64c4686 - 54
2008-06-20T07:45:55 [INFO] Token issuance request to FS failed: ValidationFailure

I don't think I can help you with this.  It looks like ADFS doesn't think the digital signature coming from the Sun OpenSSO signed token is valid for some reason.  I think you might need to investigate with Sun and MS directly. 

Hi, I got the exact same error. How did you solve the problem? Is it on ADFS side which failed caculate the signature?

In the message from the original post, you can see from the log that ADFS is complaining that the signature on the signed XML generated by the other system (Sun OpenSSO it looks like) failed.  No details are given as to what was wrong with the signature, but it looks like it failed at a pretty low level as the error didn't say that the there was a trust problem with the cert chain or a CRL problem.

Based on what I can see, it looks like the physical signature is corrupt somehow.

The signature in the SAML token is base64 encoded. I've decoded it and it's different from the one printed in the logfile - which I believe is the signature ADFS calculated. So I'm kind of interested in how ADFS calculates that signature...

I think it just uses SignedXml.CheckSignature, so you can probably write a little test program to grab the SAML token as reported from the log file and feed it into that function.

My guess is that there is a white space/canonicalization problem here.  In a digital signature, each byte of data is significant, but in XML, white space is not really that important so there is a "tension" with XMLDSig in this regard.  I've read a few newsgroup threads from crypto experts who complain that the XMLDSig specification itself is at fault here because it underspecifies details related to white space handling and other canonicalization issues that can cause these types of problems.

I'm just guessing though.

Ok, By google I found this:
The XML signature is sensitive to the method used to serialize the security token.  The entire WSE3 SecurityTokenResponse is first serialized to an instance of XmlDocument. The solution turned out to be to use DocumentElement.OuterXml instead.
I don't know too much about .NET and how could I do this? I'm trying to setup ADFS to federate with OpenSSO using the sample claimapp in ADFS document.

The problem here appears to be that the form post coming from OpenSSO is providing the SAML token in such a way that when ADFS reads it back in, the XML signature is no longer valid.  I can't think of anything you can do easily on the ADFS side to correct this.  It sounds like more of a problem on the OpenSSO side with interop.

I can say with certainty that I have NEVER seen this type of low level canonicalization problem with any other product of code base implementing WS-Fed PRP.

Have you checked with Sun to see if this is a known issue and if there is something that can be done on their side to correct it?

You might also open a ticket with Microsoft and see if you can get them to tell you exactly what the problem with the XML is.  ADFS is basically just reading the url-decoded form parameter wresult in from the form post as a string, uses that string to build the XML and then pulls the SAML token out of the inner portion of the SecurityTokenResponse.

Hi - I work on the OpenSSO project here at Sun. Vincent pasted his log output into an issue on OpenSSO - https://opensso.dev.java.net/issues/show_bug.cgi?id=3927 . I pasted his assertion into a PHP test harness (just doing basic XML dsig) and it verifies fine. I haven't seen this sort of issue before (apart from on this page) so I'm at a loss. With my cert and private key 'it just works'.

Anyway, if we figure it out I'll post the resolution here for the record.

Thanks for stopping by our humble corner of Internet ADFS knowledge sharing.  :)

Have you guys done interop verification with Microsoft on ADFS V1?  If this was a common problem with ADFS, I would have expected this to show up then, so perhaps this is a more subtle defect?

This sounds to me like a low level XML DSig issue that is probably related to some sort of canonicalization issue.  I would not be surprised if the problem was somewhere in the .NET XML core and not actually related to the ADFS code base itself since it uses the underlying .NET core stuff for dsig.  I also would not be surprised that this type of issue might generate an argument as to whose problem it was.  :)

That said, there appears to be some sort of a problem here that needs to be figured out.

I can try to put you in touch with my contacts at Microsoft to examine the issue if that would be helpful.  I don't work there, but I do have some friends on the product team.  FWIw, I know they are excited about your project because I once asked one of their lead architects for recommendations on clean, inexpensive options for Java-based shops looking to support WS-Fed PRP and they recommended OpenSSO to me.  I've repeated this advice several times to some of my business partners, although I don't think any of my company's current partners are using it yet.