IdP "Unable to encrypt assertion"
Yeargan, Yancey
To date, we interoperated with Shibboleth SPs only and had no trouble with this. This past week, we tried to add a new outside vendor's SP (which is not running Shibboleth) and our IdP says it is "Unable to encrypt assertion" with this SP. Perhaps someone will help educate me on this topic. I have a guess, but want to confirm before going back to the vendor with this.
Here's my best guess so far:
Must the X.509 subject name CN value in the SP's certificate match the SP's DNS host name?
Here is the SP metadata that we received from the vendor. I redacted references to the vendor and certificate data.
<EntityDescriptor entityID="[redacted]" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="encryption">
<KeyInfo>
<X509Data>
<X509Certificate>[redacted]</X509Certificate>
</X509Data>
</KeyInfo>
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
</KeyDescriptor>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://proofing.[redacted]/saml/unt" />
</SPSSODescriptor>
</EntityDescriptor>
The X.509 certificate contained in the SP metadata has a valid date range. However, the CN value in the X.509 subject name does not match the SP's DNS host name (from Location="https://proofing.[redacted]/saml/unt"). The SP's certificate contains saml.vendor.com and the SP's DNS host name is proofing.vendor.com. A name mismatch is the only thing I can see that may be causing the IdP to refuse to encrypt assertions, but the debug level logging output does not explicitly say why. So I am asking an expert to confirm (or reject) my hypothesis.
The debug output from idp-process.log from this morning.
08:51:33.684 - DEBUG [org.opensaml.xml.security.credential.criteria.EvaluableCredentialCriteriaRegistry:73] - Registry located evaluable criteria class org.opensaml.xml.security.credential.criteria.EvaluableKeyAlgorithmCredentialCriteria for criteria class org.opensaml.xml.security.criteria.KeyAlgorithmCriteria
08:51:33.685 - DEBUG [org.opensaml.xml.security.credential.criteria.EvaluableCredentialCriteriaRegistry:73] - Registry located evaluable criteria class org.opensaml.xml.security.credential.criteria.EvaluableEntityIDCredentialCriteria for criteria class org.opensaml.xml.security.criteria.EntityIDCriteria
08:51:33.685 - DEBUG [org.opensaml.xml.security.credential.criteria.EvaluableCredentialCriteriaRegistry:73] - Registry located evaluable criteria class org.opensaml.xml.security.credential.criteria.EvaluableUsageCredentialCriteria for criteria class org.opensaml.xml.security.criteria.UsageCriteria
08:51:33.685 - DEBUG [org.opensaml.xml.security.credential.criteria.EvaluableCredentialCriteriaRegistry:104] - Registry could not locate evaluable criteria for criteria class org.opensaml.security.MetadataCriteria
08:51:33.686 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:904] - Could not resolve a key encryption credential for peer entity: [redacted]
08:51:33.702 - 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 [deleted stack trace followed this]
Thanks,
Yancey
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Cantor, Scott
>
>Here's my best guess so far:
>Must the X.509 subject name CN value in the SP's certificate match the
>SP's DNS host name?
No.
>Here is the SP metadata that we received from the vendor. I redacted
>references to the vendor and certificate data.
If that's the metadata you're using, then it would work, unless the log
includes some low level indication of why encryption would have failed. I
would speculate that the cert is unusual in some fundamental way (not an
RSA key for example), or the entityID isn't correct in the request or
something like that.
-- Scott
Yeargan, Yancey
Yes, that metadata (other than redactions to conceal the vendor's identity) is verbatim from the SP metadata file we are using with our IdP (Shibboleth IdP v2.3.2).
Concerning a possible entityID mismatch, if I override SAML2SSOProfile with encryptAssertions="never" for this SP, then the IdP responds by sending a signed assertion containing an attribute statement to the SP and the vendor confirms that the SP received the response and was able to extract the attribute with no errors. For the sake of being thorough, here is the SAML request from the debug logs. I verified that the entityID matches the SP metadata.
08:51:27.131 - DEBUG [PROTOCOL_MESSAGE:112] -
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://proofing.[redacted]/saml/unt" Destination="https://sso.unt.edu/idp/profile/SAML2/Redirect/SSO" ForceAuthn="false" ID="s2bb6b184b6a1ca93a4554be3c9447ecbedaf53a98" IsPassive="false" IssueInstant="2011-09-26T13:51:27Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">[entityID redacted]</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="[redacted]" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"/>
<samlp:RequestedAuthnContext Comparison="exact" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Concerning the SP certificate itself (possibly being a non-RSA key or something), here [below] is the output from 'openssl x509 -text' on the certificate data contained in the SP metadata.
If not the SP metadata format, the SP certificate format, or an entityID mismatch, what does that leave?
What should I be looking for in debug logs? I keep looking over them and nothing is sticking out yet. My searches of the list archive have not borne any fruit yet.
====================
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1276694008 (0x4c18cdf8)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority - L1C
Validity
Not Before: Sep 17 15:29:31 2010 GMT
Not After : Jan 1 15:59:30 2014 GMT
Subject: [redacted]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
[binary data]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.entrust.net/level1c.crl
Authority Information Access:
OCSP - URI:http://ocsp.entrust.net
X509v3 Certificate Policies:
Policy: 1.2.840.113533.7.75.2
CPS: http://www.entrust.net/rpa
X509v3 Authority Key Identifier:
keyid:1E:F1:AB:89:06:F8:49:0F:01:33:77:EE:14:7A:EE:19:7C:93:28:4D
X509v3 Subject Key Identifier:
CA:62:14:B6:65:03:B8:45:AF:A3:52:1C:20:4D:71:99:2B:9A:75:A2
X509v3 Basic Constraints:
CA:FALSE
Signature Algorithm: sha1WithRSAEncryption
[binary data]
====================
Cantor, Scott
>
>If not the SP metadata format, the SP certificate format, or an entityID
>mismatch, what does that leave?
Not much.
>What should I be looking for in debug logs? I keep looking over them and
>nothing is sticking out yet. My searches of the list archive have not
>borne any fruit yet.
No idea. Probably going to be a Brent question or you'd have to go trace
the code and see what else might lead to that message.
Cantor, Scott
EncryptionMethod element. I don't know of the IdP using that, or doing
anything but ignoring it, but you might try removing it.
If that fixes it, please file a bug.
Brent Putman
On 9/26/11 4:19 PM, Cantor, Scott wrote:
> Ian noted privately that one oddity about the metadata you had was the
> EncryptionMethod element. I don't know of the IdP using that, or doing
> anything but ignoring it, but you might try removing it.
I don't think that EncryptionMethod should cause any issue, it's
basically ignored at this point.
However: if the metadata snippet that was previously sent was literally
what you are loading: that's not valid, b/c KeyInfo, X509Data and
X509Certificate elements don't have a namespace prefix. Due to the
default namespace being declared to the SAML 2.0 metadata one, they
would be in that namespace and hence "unknown". Since I think we ignore
unknown elements, they would therefore not be "seen" effectively, so the
key would not be resolved. Double-check that and, if missing, try adding
the appropriate xmlns decl and prefix to those elements from the XML
Signature namespace.
Otherwise, Scott already covered all the issues I can think of, it's
some variant on one of those. One remote possibility is that your Java
JRE platform might be defaulting to a security provider which produces
Key objects where in this case the algorithm is something other than the
string "RSA". I think we should be logging what it's matching on
somewhere on either DEBUG or TRACE. But double-check the above issue
first.
Yeargan, Yancey
Oh, missing XML namespace would certainly do it if Shib is
ignoring those. That sounds promising. I'll test that later
tonight and report back with the result.
Just FYI, the vendor said they are using Oracle (formerly
Sun, now ForgeRock) OpenSSO. I have not asked how the
metadata was generated.
Yancey
Yeargan, Yancey
Success! I added the missing XML namespaces to the SP metadata file and everything is now working exactly as expected. I also sent the updated SP metadata file back to the vendor.
Missing XML namespace declarations were preventing Shibboleth from seeing the [XMLsig] defined KeyInfo, X509Data, and X509Certificate elements (and the [XMLenc] defined EncryptionMethod element, even if the Shibboleth IdP currently ignores it).
Knowing that I was no longer searching for an encryption issue but rather a metadata issue, I then looked over the earlier debug output yet again and did not see any messages about discarding any part of the SP metadata. Is element discarding a feature of OpenSAML or of Shibboleth? Are there any messages logged when this occurs? It would be very nice to have such a message logged at the INFO level, if possible.
Many thanks to all of you who helped to troubleshoot this issue!
Yancey
Cantor, Scott
>
>Knowing that I was no longer searching for an encryption issue but rather
>a metadata issue, I then looked over the earlier debug output yet again
>and did not see any messages about discarding any part of the SP
>metadata. Is element discarding a feature of OpenSAML or of Shibboleth?
>Are there any messages logged when this occurs? It would be very nice to
>have such a message logged at the INFO level, if possible.
The IdP when not schema validating doesn't reject invalid content in a
variety of scenarios. If you want stricter behavior (and you don't have a
trustworthy supplier of metadata), you would need to add a validation
filter. That's all there is.
-- Scott
Yeargan, Yancey
I added the schema validation filter for all relying parties and corrected a couple of errors that were discovered as a result. Thanks for the tip. I'll sleep better now.
Yancey