I think the OpenSAML structures for configuring the algorithms in all the different cases are good for creating unambiguous rulesets we can combine safely, but for practical use they're hard to wire up and use easily, and the combinations are getting worse (SHA1/2 for signing, GCM/CBC for encryption, OEAP digests, etc.).
I think for the common cases where we don't have to override blacklists or do anything but just specify alternatives we should develop some shorthands, perhaps as factory beans, and use those to actually wire up the SecurityConfiguration objects to use.
Environment
None
Activity
Scott Cantor
July 18, 2019 at 12:11 AM
Filter is done, docs TBD.
Scott Cantor
July 16, 2019 at 8:44 PM
Started thinking about this in a little more detail, but I think I'm reaching the conclusion that it's best to leave this to metadata rather than add more code to statically configure things. The reality is that defaults are always going to be hard to change without breaking so much stuff that I just don't know how much real change we'll see there.
The gap right now is really the inability to add the algorithm extensions to external metadata so I think it's back to needing a metadata filter and just using the mechanism we already have for overriding this.
I think the OpenSAML structures for configuring the algorithms in all the different cases are good for creating unambiguous rulesets we can combine safely, but for practical use they're hard to wire up and use easily, and the combinations are getting worse (SHA1/2 for signing, GCM/CBC for encryption, OEAP digests, etc.).
I think for the common cases where we don't have to override blacklists or do anything but just specify alternatives we should develop some shorthands, perhaps as factory beans, and use those to actually wire up the SecurityConfiguration objects to use.