AES256-CBC for encryption?
cantor.2 at osu.edu
Fri May 10 18:00:59 EDT 2019
On 5/10/19, 3:22 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> We're federating with a vendor, CrowdStrike Falcon,
> First question: is it a bad idea from a security standpoint to offer this? That is, is it any worse than AES128-CBC?
No, not really.
> Second question: Is it as easy as a new security configuration bean that I could associate with their relying party config
> that looks like this?
Yes, but the problem with the way the security stuff works is that you have to plugin a top level object called a SecurityConfiguration that contains all the signing and encryption settings in one structure. So when you want to change one part, you have to be careful to create the overall object to carry what you want, and the wiring can get sort of ugly with more duplication than would be ideal.
If you control the metadata, you might want to consider using the algorithm extension metadata Shibboleth supports that lets you embed an EncryptionMethod element in the metadata to tell it what algorithm to use. The SP generates metadata with that extension in it, so if you have one handy somewhere you could look at what it generates for a sample.
> Just wanted a sanity check before shooting myself in the foot.
You're not off base at all, it's just sometimes a bit tricky to override only what you want. I suspect we'll end up adding a MetadataFilter to add in those algorithm extension elements because it's a lot simpler to do that than muck with the wiring.
More information about the users