Attribute filter

[Cantor, Scott]

On 6/24/14, 12:16 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>> I need to get straight what's in 2.4 and what's new here and make sure
>>the
>> names make sense.
>
>In case it helps and to save you time V2 has 4 EntityAttribute match
>functors:

Thanks, got it.

>Also in 2.4 is
>
>AttributeInMetadata.
>(https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirement
>At
>tributeInMetadata)
>
>This has been ported to V3 but works on IdP Native
>Attributes/RequestedAttributes.  SAML [Requested]Attributes are converted
>when the metadata loads by reference to the current attribute resolver
>configuration.   
>
>The net result is the same as V2.4 except
>1) This can also be in a PolicyRule (but only with a wildcard attributeID)
>2) This should have significantly better behaviour for non string
>attribute
>values (scoped, XMLObject)

Right, and that (along with the case of query content) were the two main
use cases for implementing the generalized mapping capability.

Using it for EntityAttribute policy is definitely a secondary case that's
usually going to be more trouble than it's worth.

>In V3 I have added a type saml:EntityAttributeInMetadata which is
>configured
>and behaves just as saml:AttributeInMetadata *EXCEPT* that the mapped
>attributes come from the EntityAttributes on the entity, not from the
>RequestedAttributes on the ACS.

Ok, the name on that is what was confusing me every time I saw mentions of
it. I think it would be better to rename it along the lines of the
original EntityAttribute-based functors in 2.4 because it's really just an
enhancement of those.

In retrospect, AttributeInMetadata is a terrible name itself, but I think
I picked that after not being able to come up with anything good. Seems
like RequestedAttributeInMetadata would have been better, though, maybe we
should alias that. But back to the earlier point.

How about using "AttributeRequesterMappedEntityAttributeMatch" or maybe
just "MappedEntityAttributeMatch" for the new one? There is nothing other
than AttributeRequester, so that's probably redundant now, and I think
there's no such thing as a regex there, right, since it's directly
comparing mapped values?

(That leads to an interesting question...how would we support inexact
matching rules for mapped values, since the syntax for that would have to
be extensible? I suspect the answer is we leave that to scripting for now.)

And I wonder if we should alias/rename some of the older functions that
have AttributeRequester in them if there's no longer an Issue parallel, to
shorten the names.

-- Scott