More on Attribute Filtering.

[Cantor, Scott]

On 3/18/13 8:03 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>I'll agree that the documentations makes it a lot easier for a neophyte to
>understand, but it doesn't match the schema (although sadly it matches V2)
>and that will get us into trouble in V3.   For a start in V3 we will
>implement correctly things which have always been schema-valid such as:
>
><PolicyRequirementRule xsi:type="basic:PrincipalNameString" value="jsmith"
>attributeID="eptid" />

A key point: that is *not* schema valid. At least I don't believe so.

<element name="PolicyRequirementRule" type="afp:MatchFunctorType">


The MatchFunctorType base type(s) do not include attributeID. Neither does
basic:PrincipalNameString.

Ergo, it's not valid.

I think that means some of your confusion stems from incorrect
assumptions. It may be that V2 is broken or was sharing code such that
certain properties appeared legal or were being permitted, but they aren't
allowed by the schema.

In the case of PolicyRequirementRule, the only time you can have
attributeID is if the rule type specifically allows, and defines, it. Then
it has specific meaning.

Secondly, AttributeRule has attributeID so that it ties the rule to a
specific attribute in the absence of an override within the Permit/Deny
rule's match functor type. In that layer, the absence of an attributeID
means "operates on the attribute supplied by the engine". If set,
attributeID will mean "operates on the attribute(s) in the filter context
of that ID".

It can be weird, but it's precisely defined.

As a general statement, we need to be less concerned with sharing code and
more with just implementing the logic. We can factor the code afterward,
if at all.

-- Scott