Version 3.4 metadata driven overrides

[Michael A Grady]

> On Oct 22, 2017, at 5:22 PM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
> 
>> I know all the profiles one start with the following, but this isn't a profile one.
> 
> Ah, yes, subtle point. The point of the property prefixes isn't really to target the specific settings by name but to target the setting that would apply to that request. In other words, it builds the property to look for by using the current request's profile ID. So nominally you could even vary the responderId by profile with this trick just like if you were doing it with a lookup function.


Thanks. So one that would apply to all profiles would just be the following, correct?

  http://shibboleth.net/ns/profiles/responderId <http://shibboleth.net/ns/profiles/responderId>

I'd also like to bring up attribute release, and see what the Shib team thinks of the following. I know that at least you (Scott) have given this some thought in the past. One could define a standard entity attribute name, and the values of that would be the "standard" ID/FriendlyNames (as in the attribute-resolver-full.xml) of the attributes to be released. And then, of course, distributing an attribute filter file with rules in it like the following:

<AttributeFilterPolicy id="release_EPPNtoTagged">
    <PolicyRequirementRule xsi:type="EntityAttributeExactMatch" 
      attributeName="http://shibboleth.net/ns/attributes/releaseAllValues <http://id.incommon.org/category/attributeRelease/releaseAllValues>" 
      attributeValue="eduPersonPrincipalName" />
    <AttributeRule attributeID="eduPersonPrincipalName">
        <PermitValueRule xsi:type="ANY" />
    </AttributeRule>
</AttributeFilterPolicy>

etc. 

The other option would be to define an entity attribute name per attribute, but I don't see the advantage in that unless one was going to somehow work "values to be released of a given attribute" into that. (Although I'm sure how one would leverage those values in pre-embedded release rules. And trying to go down to the level of per-value control thru entity attribute tagging seems a step too far.)

What do you think? Does the Shib team want to define one or more entity attribute names that could potentially be leveraged as one option to control attribute release? Would you prefer the value set of such an entity attribute to be the urn:oid form of the names, rather than the FriendlyNames? Have you had some different model for such tagging in mind?

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20171022/83c93fc0/attachment.html>