Encryption

[Tom Scavo]

(just adding two cents to what Scott said)

On Thu, Sep 4, 2014 at 2:17 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/4/14, 3:11 AM, "Lohr, Donald" <lohrda at jmu.edu> wrote:
>>
>>For starters, my Shibboleth 2.x knowledge is very limited, I'm a newby.
>>The above question is from a previous Shibboleth admin. I do not fully
>>understand this question we asked
>> the integrator.
>
> SAML long ago deprecated the back-channel as an exchange path. Your
> assertion travels from the IdP through the browser to the SP. The data
> there is readable. XML Encryption makes it much harder to read if there's
> malware in the client.

So, for the SP to fully support XML Encryption in multilateral
fashion, three requirements must be met:

1) The SP must publish its encryption certificate in metadata (which
the IdP uses to encrypt the assertion over the wire).

2) The SP must be configurable with the corresponding private key (so
that it can decrypt assertions received from the IdP).

3) The SP must be simultaneously configurable with TWO private keys,
which are tried in turn until a successful decryption occurs.

This last capability is often overlooked. Without it, an SP is unable
to safely rollover an encryption certificate in metadata, in which
case the relationship between IdP and SP is reduced to a manual,
bilateral arrangement.

>>My question for the group, does Shibboleth 2.x support x509 signature and
>>certificate validation.
>
> Yes, but the IdP isn't validating the signature, it's creating it. And you
> don't want the vendor doing X.509 anything, you want them pulling the key
> out of the certificate you give them or from the metadata if by some
> miracle they support metadata, and using that directly.

Right, and you definitely want the SP to support metadata (i.e.,
multilateral federation). That would be at the top of my "must have"
list, whereas encryption would be merely a "nice to have."

Tom