IdP "Unable to encrypt assertion"

[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



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