More on Attribute Filtering.

[Rod Widdowson]

Just for general information, the Attribute filtering is being a bit of a
can of worms (which has opened up further as I write this mail)

1) I have changed the wiki page
(https://wiki.shibboleth.net/confluence/x/dYBX ) to reflect the decision we
came to on the filter architecture last week.

2) I have also added words about identification of filters (I propose to
generate a name if one is not available and log the name and a description
at level INFO).  I have put in JIRA case IDP-277 to do this and to sanitize
the logs as a result.

3) There is still some ugliness in the code, I need to think about what the
real problem is and talk to Tom.  But mostly.....

4) The work I have done to make the objects reflect the schema made me look
closely at the documentation and realized that there is a nasty gap between
V2 and the documentation on one side and V3 and the Schema on the other.

In (for instance) the documentation for AttributeValueString
(https://wiki.shibboleth.net/confluence/x/IIFC) it states that attributeID
is associated the AttributeValueString rule, whereas in fact (in the schema)
is it associated with the PolicyRequirementRule.  As such, providing an
attributeID in a PermitRule or a DenyRule is non schema-valid (as well as
being meaningless).  

It turns out that in V2 attributeID *is* part of the implementation of the
AttributeValueString rule and that it is ignored in a value matching role.
In the V3 implementation, the attributeID is part of the
PolicyRequirementRule.   But the upshot is the same in that providing an
attributeID in a PermitRule or a DenyRule is ignored.

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" />

attributeID="eptid" is associated with PolicyRequirementRule and
value="jsmith" is associated with PrincipalNameString and there is an sort
of implied AND, although the semantics are implemented as  "If the principal
is jsmith then apply the following filter to all values of the attribute
eptid".  I am not convinced that this is the same as an implied AND in the
case of a DenyRule.

More worrying is the case described in the documentation:

<PolicyRequirementRule xsi:type="basic:AttributeValueString"
attributeID="uid" value="jsmith"/>
 
In V3 as it stands (or will be when I check in the code I wrote yesterday)
this will be implemented as:

1) Apply this rule to all attributes of with name "uid" (PolicyRequirement)
2) If any attribute (not just "uid" has value "jsmith") then this rule
should be applied (ValueRule)

This is *not* the same as the documentation or the V2 implementation which
is "if the attribute called "uid" has any value "jsmith" then the rule is
applicable.

We therefore have to fix the implementation so that it does what people
expect.    It might be that the easiest thing is to push the attributeID
down to those rules where it is meaningful but:

- This could complicate the parsers - unless we change the schema (and note
that the parsers will be not more complicated than they must be in V2).  
We might be able to fix this in the code rather than the parsers.  This
would have the benefit that the complexity of the semantics would be
reflected in the code, but the disadvantage that the code would become....
well, complex.

- Therefore should we change the schema so that the valid but (AFAICS) not
implemented example I showed above becomes schema illegal (albeit
implemented)? This has the added benefit that the parsers become more schema
conformant.

- If so should we strip out all the current V3 code which handles
attributeId as part of a policy requirement role?

However this schema and semantics are shared with the SP, so we come the
full circle.

Thoughts?

Rod