v3 Relying Party Overrides

[Cantor, Scott]

On 4/9/15, 11:24 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>The relying-party override mechanism in v3 is awesome and I have all sorts of use cases that I'm trying to implement. Initially I thought that overrides are applied relative to the default relying party, but quickly learned they're relative to bean definitions in relying-party-system.xml.

Chad rejected merging very early on, so it's never worked that way. I think it also would be very complicated to do, because it would mean building something like what Brent built for security settings. I'm not sure there's enough value there for most people to justify that level of complexity.

> Would it be feasible for overrides to "merge" with default relying party values? That seems powerful and it would help avoid repetition in some of my use cases.

It's problematic because it makes it difficult to "turn off" something, expressing negation isn't that easy. The SP has had similar problems in this respect, and as a result the override behavior gets confusing or in some cases just doesn't work right.

I also think (for the specific case of the Default and a single override) you end up in the same place by just using your own parent beans, and changing the parent beans the DefaultRelyingParty happens to use. Essentially you just push the merging to Spring.

>Now a question: how do intersecting overrides work? It appears to be a "first one wins" behavior, but I wanted to clarify.

It's ordered (it's a list) and it applies the first one it can.

> I would prefer a "merge" behavior in some if not all cases.

I don't personally believe that could ever be totally unambiguous, but the entire RelyingPartyConfigurationResolver is itself replaceable if somebody wants to experiment. In addition, it's possible, I think to put a "live" object into the list of configurations that isn't just a simple bean with a condition attached, but actually dynamically returns settings based on the request when the resolution process runs. I never tried it, I'm just saying the parent bean to create an override is just a default to allow simple static settings to work.

> For example, a relying party "by group" override could set some federation-wide
> defaults, while "by name" overrides could provide one-offs without repeating the defaults for the entire federation. Make sense?

Specific cases always make sense, but it would have to handle every edge case and make it understandable.

-- Scott