Using metadata-driven overrides and relying party config

[Cantor, Scott]

On 1/14/21, 11:31 AM, "users on behalf of Michael Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:

>    So when  one turns on support for metadata-driven overrides in relying-party.xml, does that mean you need to use
> either metadata-driven for a given SP, or an override in relying-party.xml, but not both? Can they be combined?

They should combine properly [1], but that code is tricky and I'm sure there may be bugs. The reason it's suppsoed to work is that there's a chain of beans involved and Spring is *supposed* to apply a parent bean's properties before the child's properties. That should result in the static setter being called after the setter that injects the function lookup, so the static setter "replaces" the dynamic function with a constant/static function.

>  Clearly its best to be consistent and not use both in general, at least not for the same SP. 

I do it in some cases but I haven't exhaustively tested or tried to combine specific metadata signals with static signals for the same setting. I just tested the basic behavior to see if it matched what Spring claims it does.

> I do know from a recent test that setting http://shibboleth.net/ns/profiles/securityConfiguration  to ties into a new 
> signing cert in the metadata for a SP does not work if there is then a RP override that overrdies what to sign.

Maybe you're expecting the opposite, and the opposite is not the intended behavior. The static configuration SHOULD override the metadata. That is what I would expect as a deployer.

-- Scott

[1] I define properly as "the configuration should override the metadata".