spring-security-saml, IdP is unable to encrypt assertion? - shibboleth

Question

I'm attempting to test our Spring-Security-SAML setup for Shibboleth with testshib.org.
The metadata we've generated (after being pushed through xmllint --format, for readability)is included below:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="https___sforge0.york.ac.uk_sf_saml_" entityID="https://sforge0.york.ac.uk/sf/saml/">
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDNjCCAvOgAwIBAgIEUESd6DALBgcqhkjOOAQDBQAwbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4G
A1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UE
CxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjAeFw0xNDEwMjMxNTM2MTJaFw0xNTAxMjExNTM2
MTJaMGwxEDAOBgNVBAYTB1Vua25vd24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25v
d24xEDAOBgNVBAoTB1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xEDAOBgNVBAMTB1Vua25vd24w
ggG4MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlF
XUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fG
qKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL
8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkW
cSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD
3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhQACgYEAlmBZaPGCOx/qBr/sGxjkb+FA1SPfMj2ys2OQ
joauGh53ORS8AolmE3Cwc3S2B0qA9ldhL4I2cv0ShOIz7x+JYTnrIqXtqS6essY6jG1Kpwhy4YCB
UJRwKfcyYfq1+meLbZ/vAqgvMA7/rJOQnRi/HnqzqW7wdH9BItPR6G451vmjITAfMB0GA1UdDgQW
BBQANR5pMdkq/O47PEgTBUuMQPFrtzALBgcqhkjOOAQDBQADMAAwLQIUYlj1QoLS6JGlnjsTYl/l
vFmVFL0CFQCQ/jwl1chFdPvHvzTeo+LvsOynrw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDNjCCAvOgAwIBAgIEUESd6DALBgcqhkjOOAQDBQAwbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4G
A1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UE
CxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjAeFw0xNDEwMjMxNTM2MTJaFw0xNTAxMjExNTM2
MTJaMGwxEDAOBgNVBAYTB1Vua25vd24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25v
d24xEDAOBgNVBAoTB1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xEDAOBgNVBAMTB1Vua25vd24w
ggG4MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlF
XUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fG
qKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL
8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkW
cSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD
3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhQACgYEAlmBZaPGCOx/qBr/sGxjkb+FA1SPfMj2ys2OQ
joauGh53ORS8AolmE3Cwc3S2B0qA9ldhL4I2cv0ShOIz7x+JYTnrIqXtqS6essY6jG1Kpwhy4YCB
UJRwKfcyYfq1+meLbZ/vAqgvMA7/rJOQnRi/HnqzqW7wdH9BItPR6G451vmjITAfMB0GA1UdDgQW
BBQANR5pMdkq/O47PEgTBUuMQPFrtzALBgcqhkjOOAQDBQADMAAwLQIUYlj1QoLS6JGlnjsTYl/l
vFmVFL0CFQCQ/jwl1chFdPvHvzTeo+LvsOynrw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sforge0.york.ac.uk:443/sf/saml/SingleLogout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sforge0.york.ac.uk:443/sf/saml/SingleLogout"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sforge0.york.ac.uk:443/sf/saml/SSO" index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
We upload this to testshib.org via the "Register" option, and then hit our running service at $contextPath/saml/login, which correctly redirects us to testshib.org, which accepts the "myself:myself" credentials, and redirects back to our site.
On our end, we then see (in our logs):
2014-10-29 10:12:52,002 278662 [1817318774#qtp-1246086685-8] INFO o.s.security.saml.log.SAMLDefaultLogger - AuthNResponse;FAILURE;144.32.136.27;https://sforge
0.york.ac.uk/sf/saml/;https://idp.testshib.org/idp/shibboleth;;;org.opensaml.common.SAMLException: Response has invalid status code urn:oasis:names:tc:SAML:2.0
:status:Responder, status message is Unable to encrypt assertion
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:113)
at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:82)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
Pulling the logs off testshib.org shows:
06:12:51.694 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:927] - Could not resolve a key encryption credential for peer entity: https://sforge0.york.ac.uk/sf/saml/
06:12:51.695 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:289] - Unable to construct encrypter
org.opensaml.xml.security.SecurityException: Could not resolve key encryption credential
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.getEncrypter(AbstractSAML2ProfileHandler.java:928) ~[shibboleth-identityprovider-2.4.0.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:286) ~[shibboleth-identityprovider-2.4.0.jar:na]
As suggested in other questions, I've ensured that there's a KeyDescriptor tag in the metadata (in fact, two, each with a "use" attribute). I've also tried mangling the metadata by hand to use a single KeyDescriptor, with and without the "use" attribute, all of which seem to produce similar results.
I can supply further details, for example, more log contents, spring xml config, etc. on request, but I am not sure how relevant it is, so I've chosen to leave them out for the time being.
I'm not sure how to convince testshib.org to use the key supplied in the metadata, or if it's something wrong with the metadata we're providing to testshib.org? Any ideas as to how one might go about getting our testshib login to work?

Answer 1

I posted in the Shibboleth.net mailing list, and Ian Young suggested that my certificates may be at fault.
In the end, here was my full response to the mailing list, including what I did to fix it:
Re-creating the keystore seemed to fix it. Keytool was behaving very oddly attempting to get info from keytool in this case (keytool -printcert -alias skillsforgetrustfabrickey -keystore sfTestKeyStore.jks) seemed to hang the keytool process (!).
I deleted the old keystore and re-created it:
keytool -genkeypair -keysize 2048 -keyalg rsa -validity 730 -keystore sfTestKeyStore.jks -alias skillsforgeTrustFabricKey
Used the same passwords, etc. as specified in my configuration and it mysteriously sprang to life after restarting Jetty & re-requesting/re-registering my metadata.
Although I don't have a record of exactly how I generated the keypair previously, I'm fairly certain that I used the same (or at least very similar) method previously. Clearly I must've mis-typed something when I setup the keystore in the past.