Attribute Filtering Engine Architecture

The IdP's Attribute Filtering Engine is a policy engine that determines what information, expressed as attributes as described in the Attribute Resolver Design design document, is released by the IdP. This gives the author of the filtering policies the power to permit or deny the release of information regardless of what a requester may have asked for.

Anatomy of an Attribute Filter Policy

An attribute filter policy contains:

1. an ID to identify the policy
2. a policy requirement rule to determine if the policy applies to an attribute filter context
3. attribute rules to permit or deny the release of attribute values

Anatomy of an Attribute Rule

An attribute rule contains:

...

Rules may be for permitting values (releasing the values for which the matching function evaluates true) and denying values (blocking the values for which the matching function evaluates true).

The Filtering Process

The attribute filtering process is invoked with a given collection of attributes (probably having come from the attribute resolver) and proceeds as follows:

...

There are a couple things to note about this process. First, the value set of an attribute is not adjusted until the end of the filtering process is complete. This means that all policy requirement rules and attribute value filters operate on the full, unfiltered, set of values for attributes. Second, only those values that explicitly permitted and not denied are released by the filter engine. If a value is never matched by an attribute value filter it will never be released.

Separating <PolicyRequirementRule/> from <AttributeRule/>

In V2 many different rules were implemented. Some were more applicable to policy rules (for instance AttributeRequesterString) and some were more applicable to attributes rules (for instance AttributeValueRegexp).

...

These interpretations were coded up in the implementation of each individual rule, and so were not necessarily consistent.

Representation Take 1, Take 2, Take 3, Take 4, Take 5, Take 6

In the schema a <MatchFunctor/> can be placed either in a <PolicyRequirementRule/> or in a <PermitRule/> or a <DenyRule/>

In all IdP implementations to date this bimodality has been handled by having an interface with methods to support both types of operation. This implementation explicitly separates these two types which are now represented by two interfaces

PolicyRequirement:

This has a single method which takes a FilterContext and returns a tristate (yes/no/fail)

Matcher

This has a single method which takes a FilterContext and an attribute and returns a (potentially empty) Set of attribute values with null representing the “fail” condition.

Logical operators (and/or/not)

Each of these have two implementations one of which implements PolicyRequirement and the other of which implements Matcher. The parsing code inspects the provided element and instructs Spring to create a bean of the correct sort. We need to ensure that the setter/getters are the same in both cases. Job done.

All other operators

These implement only one of  PolicyRequirement or Matcher, whichever allows the more natural implementation.

...

AttributeInMetadata filter.

AttributeInMetadata will be implemented to be compatible with the V2.4 and later implementations.

...

As a final note, correct operation of this filter will require that the attribute values can be compared.  All AttributeValue implementations explictly implement #equals(), but  XMLObjectAttributeValue delegates to OpenSAML which tends to not implement #equals(), so we may seek to issue warnings in this case.

Filter Identification

Filter rules have optional identifiers.  In V3 we want to provide logging information based on these identifiers.  The paradigm we will use is to general an identifier for anonymous rules when the filter is inititialized.  We will log (at info level) the (random, run time) name given to the filter and a self-generated description.  For instance:

Attribute Filter: Anonymous filter given name 'AB567F': Description "And filterRule of filters ["59C0F", "89034"].

Contexts

Parameters to the Attribute Filter operation are provided by the AttributeFilterContext.  In addtion, the AttributeFilterWorkContext is used as work space for the attribute filtering process; this context is entirely private to the specific implementation of attribute filtering.

A web flow that wishes to invoke the Attribute Filtering subsystem must do the following.

...