title: SAML Secured AuthnRequest Fails
body: <p>I'm not able to make a secured ECP AuthnRequest to my Shibboleth IdP. I've got a small proof of concept SP running which is based heavily on the Spring SAML extension sample app. My SP metadata was generated using the Spring SAML extension sample app's metadata generator. The signing key being used is the apollo one included with the sample app samlKeystore.jks key store, all of which is also in my own small SP app. </p>
  
  <p>In my SP metadata, I have the AuthnRequestsSigned attribute set to true like so :</p>
  
  <pre><code>&lt;md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"&gt;
  </code></pre>
  
  <p>If I set AuthnRequestsSigned to false and make the ECP SOAP POST to the IdP, it works just fine. I get the proper SOAP message back from the IdP. But if that value is true, I get a non-descriptive error message: </p>
  
  <pre><code>    &lt;env:Fault&gt;
          &lt;faultcode&gt;env:Client&lt;/faultcode&gt;
          &lt;faultstring&gt;An error occurred processing the request.&lt;/faultstring&gt;
          &lt;detail/&gt;
      &lt;/env:Fault&gt;
  </code></pre>
  
  <p>I look in the Shibboleth (IdP) logs and see:</p>
  
  <pre><code>Attempting to extract credential from an X509Data
  Found 1 X509Certificates
  Found 0 X509CRLs
  Single certificate was present, treating as end-entity certificate
  Credentials successfully extracted from child {http://www.w3.org/2000/09/xmldsig#}X509Data by provider org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider
  A total of 1 credentials were resolved
  </code></pre>
  
  <p>This displays twice in the log for my transaction. My assumption is because it's finding the certificate in the request and in my SP metadata. Further down in the log during this same transaction I see this followed by a stack trace:</p>
  
  <pre><code>Attempting to validate signature using key from supplied credential
  Creating XMLSignature object
  Validating signature with signature algorithm URI: http://www.w3.org/2000/09/xmldsig#rsa-sha1
  Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl'
  Signature did not validate against the credential's key
  Signature validation using candidate validation credential failed
  Signature did not validate against the credential's key
  </code></pre>
  
  <p>I compared the certificate that is in the ECP POST AuthnRequest to the one in my SP metadata used for "signing" and they are the same. So I'm not sure why I'm getting this error. </p>
  
  <p>My understanding is that the IdP will take the certificate found in the <code>&lt;ds:X509Certificate&gt;</code> tag of the request (which is the public key) and make sure that's the same one defined in the SP metadata. Then use that cert to verify the signature value which is also in the request in the <code>&lt;ds:SignatureValue&gt;</code> element. If it validates then it moves forward with the AuthnRequest. Is this accurate? </p>
  
  <p>What piece am I missing?</p>
  
  <p><strong>Update 1:</strong> I've added the logging lines as suggested and here's all it shows for the ECP requests:</p>
  
  <pre><code>signatureMethodURI = http://www.w3.org/2000/09/xmldsig#rsa-sha1
  jceSigAlgorithm    = SHA1withRSA
  jceSigProvider     = SunRsaSign
  PublicKey = Sun RSA public key, 2048 bits
    modulus: &lt;long value here&gt;
    public exponent: 65537
  Signature verification failed.
  </code></pre>
  
  <p>One thing of note, if I make a request to my SP via a browser and I'm not signed in, I get redirected to my IdP login page as expected. I check the IdP logs and see that that request was also signed and it validates. I looked at the form data sent to the IdP from the SP and see that <code>AuthnRequest</code> is also signed using the same certificate but the <code>SignatureValue</code> value are different of course. That non-ECP request data XML looks very similar to the ECP request SOAP XML yet the ECP one fails.</p>
  
  <p><strong>UPDATE 2</strong>: I'm using spring-security-saml-1.0.0.RELEASE, and Shibboleth IdP v2.4.0. Here's a sample message I'm sending to the IdP: </p>
  
  <pre><code>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
  &lt;soap11:Envelope 
      xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"&gt;
      &lt;soap11:Header&gt;
  
          &lt;/soap11:Header&gt;
          &lt;soap11:Body&gt;
              &lt;saml2p:AuthnRequest 
                  xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://1XP21VRS.mydomain.com:8080/proofofconceptapp-sso/saml/SSO/alias/conceptSSO" ForceAuthn="false" ID="a3j6fd01d0ciahe25b56i326bhe212" IsPassive="false" IssueInstant="2014-10-24T19:37:43.207Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0"&gt;
                  &lt;saml2:Issuer 
                      xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"&gt;http://1XP21VRS.mydomain.com:8080/proofofconceptapp-sso
                  &lt;/saml2:Issuer&gt;
                  &lt;ds:Signature 
                      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
                      &lt;ds:SignedInfo&gt;
                          &lt;ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/&gt;
                          &lt;ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/&gt;
                          &lt;ds:Reference URI="#a3j6fd01d0ciahe25b56i326bhe212"&gt;
                              &lt;ds:Transforms&gt;
                                  &lt;ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/&gt;
                                  &lt;ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/&gt;
                              &lt;/ds:Transforms&gt;
                              &lt;ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt;
                              &lt;ds:DigestValue&gt;mMJbjpmWr6OMP9eU70RA9TtfXGY=&lt;/ds:DigestValue&gt;
                          &lt;/ds:Reference&gt;
                      &lt;/ds:SignedInfo&gt;
                      &lt;ds:SignatureValue&gt;I6rHpgjWgl5l5sjst+VHuSUnjUaOBnPIbUrWwcAfdTDSFY2wxUuNdHpXt/YqBfP9ZKdTWZV1IjbTR666T7sa1bZawgT3UO07FoBVAc5z+AH0nCvIz+UNSqpunPTaEdUhSaGmNHSItvFtvz2fDmvZl18GwXrTz4g6vvxKkdo/FijgvYldfYYuO+obcjof1SJmpOOr1iRNvpyGQMxcaH9e07QfJO9SDcLP2elvPvwbJsGGl/n/3sIG+kIm0MECU3hv/4pLx6+SyHDXjdhdOD2HyxGL1t7iIYG1AaDX4dkIt2wH2WOyzhfO2MyykqChhRcYWFdEdgqaQW/IBLPxsVjN9g==&lt;/ds:SignatureValue&gt;
                      &lt;ds:KeyInfo&gt;
                          &lt;ds:X509Data&gt;
                              &lt;ds:X509Certificate&gt;MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE
  CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM
  MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy
  ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx
  GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w
  ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E
  5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13
  F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K
  qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON
  UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg
  0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL
  82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A
  8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu
  RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW
  bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=&lt;/ds:X509Certificate&gt;
                          &lt;/ds:X509Data&gt;
                      &lt;/ds:KeyInfo&gt;
                  &lt;/ds:Signature&gt;
              &lt;/saml2p:AuthnRequest&gt;
          &lt;/soap11:Body&gt;
      &lt;/soap11:Envelope&gt;
  </code></pre>
  
  <p>I'm pretty much just copying the response from the initial PAOS request to the SP (Spring SAML), removing the header innards, and sending that along to the Shibboleth IdP. The headers that I send are:</p>
  
  <pre><code>Content-Type: text/xml
  Authorization: Basic &lt;base64 encoded credential string here&gt;
  </code></pre>
  
  <p><strong>Update 3</strong>: Signed non-ECP AuthnRequests validate just fine. So it's only SOAP ECP AuthnRequests to the IdP where the signature fails. Any ideas?</p>
  
  <p><strong>Update 4</strong>: Still can't get this working. Any help would be appreciated.</p>