Version 3.4 metadata driven overrides

[Cantor, Scott]

On 10/23/17, 2:45 PM, "dev on behalf of Michael A Grady" <dev-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:

> That's an idea. Thinking of the UI, I've been shying away so far from thinking about RequestedAttribute config, since that seems a
> bit less "controllable" (used in metadata today, not necessarily accurate, etc.). But support for that at some point makes sense,
> and if you think that mapping everything back to that makes the most sense even in the shorter-term, that could be considered.

I'm just saying that anything expressed in terms of SAML will devolve back into that same mechanism internally in the end, and we could do that if we want to, but I doubt that's the most "friendly" way to go with this.

> But I'm kind of for simplifying assumptions to start with, and allow for 10 - 12 commonly used IDs, the IDs that you'd find in the
> distribute example resolvers, and if you want to change from those, you go in by hand and do so. At least for a first stab at this.

I would agree. I don't think it's super helpful to just keep adding layers of naming indirection, especially while a lot of this remains spread out in multiple files. I'd rather wait until we come at this from a different direction and just include this when we redesign some things.

> Another thing I've wondered, but so far have shied away from, is an embedded filter config that would be a "Not/deny". But
> there is no distributed example of a resolver ID for a "suppress" attribute. So that would have to be a property or just
> make up a value and say "if you want to leverage the standard config, use that ID, even if it means just sourcing it from the ID
> you are already creating".

You mean the FERPA type thing? I figured we'd just define something, yes. I guess some of that could be turned into properties, but I just think that's more confusing than helpful.

-- Scott