Using metadata-driven overrides and relying party config

[Michael Grady]

> On Jan 14, 2021, at 3:47 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 1/14/21, 4:43 PM, "users on behalf of Michael Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:
> 
>>   Ah, yes. Once one adds it to the DefaultRelying party, one can think of it "turned on" for evreything.  Personally, I think
>> it would be good to have such an on/off switch, and not be required at the level it is, but a good reminder that it is.
> 
> It would have been simple to globally wire it up as a default, but the problem is that opening up to metadata like this is a big, big deal if you don't take care and protect against external metadata tag injection, so that wasn't really an option.
> 
> -- Scott
> 


One would hope that Federations would prevent the addition of entity attributes starting with a namespace that is clearly  not theirs. But yes, any "global" setting should come with a warning giving an example of how to be sure metadata not under your full control should have entity attributes "with given prefixes filtered out before adding in your own.

Not suggesting it should be in place of the per-profile bean setting, but akin to having the "idp.encryption.optional" property, only use if you know what you are doing.

Of course, if one just sticks to putting all overrides into the metadata, it doesn't matter. 

--
Michael A. Grady
IAM Architect, Unicon, Inc.