Version 3.4 metadata driven overrides

[Michael A Grady]

> On Oct 23, 2017, at 6:37 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> 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.

Yes. I have to say, I work with a lot of institutions, and almost none have even had any attribute in their directory to indicate "elected FERPA suppression" or some related suppress-type indicator. So I've rarely seen it's use in attribute filter files. But it would be easy to say, "if you want to suppress sending attributes for a person", create an attribute id "suppress" with a value of true (or "yes"). And then have an entity attribute activated config in the filter that looks for that id/value, and an entity attribute of "honor suppression", and have that deny all the attributes that one creates entity attribute-based release rules for. (Again, one could get more detailed and have a "suppress entity attribute value per-attribute, so a suppress-givenName value, in conjunction with a givenName value, would release givenName to that SP unless the person in question had the attribute "suppress=true". But that again is driving the complexity up (and probably the understanding "down".)

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20171023/2ddbc5b3/attachment.html>