Security defaults

[Cantor, Scott]

On 5/17/14, 8:54 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Ah, I just missed that particular one.  I didn't know we literally wanted
>to blacklist that.  If that is the case, then we would do like I already
>did there for the MD5 signing and digest variants: put it in the
>blacklist and do NOT put it in the algorithm list.

We blacklist it now in the SP. We don't have a lot of decryption use cases
in the IdP, but we should be consistent.

>Speaking of blacklists: I suppose that for the IdP, the blacklists could
>be explicitly duplicated in the IdP global config, with merging set to
>false.  Then it becomes more explicit to people what is blacklisted, and
>theoretically makes it possible for them to easily change (although we
>obviously wouldn't recommend it, at least for the IdP-wide config).

Yes, I was planning to do that.

One thing I changed was to remove the IdP defaults when the old
relying-party syntax is being parsed. I thought it would be best just to
simplify that case and leave it identical to now, you get the library
defaults and no override capability. If you want to manipulate those
options, it pushes you to use Spring syntax.

-- Scott