IdP "Unable to encrypt assertion"

[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




On Sep 26, 2011, at 5:23 PM, Yeargan, Yancey wrote:

> 
> 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
> 
> 
> 
> On Sep 26, 2011, at 4:18 PM, Brent Putman wrote:
> 
>> 
>> 
>> 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.
>> 
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net