Shibboleth Developers

["Scott Cantor" <>]

> I screwed up the sequence of events as associated with the logfiles I
> posted (I described the failure from one SP, while posting the logfiles
> from a second SP).  So it's no wonder that the error didn't make sense.

At least I'm not chasing the impossible.

> When the testing switched from one pair oF IDPs/SPs to another that
> could be changed, the key exchange algorithm was changed from rsa-1_5 to
> RSA-OAEP, and the errors I posted to the list were from the RSA-OAEP
> exchange algorithm, which I believe this other IDP is screwing up (we
> switched this back to using rsa-1_5 after Brent suggested that, but not
> before adding the X509 certificate to the Key Exchange).

I wouldn't assume that it's their bug, I believe OpenSSL is just as likely
to be at fault. It's just that I can't do much about it either way.
 
> The original error message I should have posted was:
> 
> 2008-03-11 16:30:14 ERROR Shibboleth.SSO.SAML2 [4]: Unable to locate an
> encrypted key.

That's a more generic error that refers to an inability to locate an
EncryptedKey element, period. That's got to be there, unless you're doing
something really odd, like bulk encrypting the data with RSA or something.
There's got to be a symmetric key, and the SP does NOT supports pre-shared
symmetrics without plugging in code to do advanced key resolution for that
case.

> This shibboleth instance is only configured with a single credential
> resolver, but I guess based on that error message, it does not find any
> key with which to attempt decryption?

No, it doesn't find any key encrypted to it to decrypt.
 
> Could it be that the credential
> pair I have is marked oddly such that Shibboleth by default assumes it
> is only to be used for signing?

No.

> (I assume there is no interest in analyzing the RSA-OAEP key exchange
> problem, since I believe the problem is internal to this other product,
> but if you want more details on that, hit me off list, and I can get you
> a copy of the assertion that failed and a copy of the relevant key
> material as well)

I'm happy to look at it later, but for this problem, I need to see the XML
that is failing to include the EncryptedKey (to make sure it's actually
missing and not just a bug in my locating code).

-- Scott