Page Comparison

...

The semantics of the attribute language can be deceptive. Informally it is easy to see what is going on (for instance the last case in the example could read "If the relying party has an ID of 'https://sp.example.org' or 'https://another.example.org/shibboleth' then release all values of eduPersonScopedAffiliation". However the detailed semantics can be extremely confusing and often downright counterintuitive. This is explained in detail below. A good rule of thumb is "If it seems like a cute trick and a good idea, it isn't. Do it the obvious way."

...

During attribute filtering, the engine:

1. Examines all the <AttributeFilterPolicyGroup> elements provided (for instance across multiple files) in an unspecified order.

2. Examines all the <AttributeFilterPolicy> elements within each <AttributeFilterPolicyGroup>, again in an unspecified order.

3. For each policy, if the <PolicyRequirementRule> is true:

   1. Applies each of the child <AttributeRule> elements, such that:

      1. The attributes (and their values) returned by <PermitValueRule> get added to a "permit list".

      2. The attributes (and their values) returned by <DenyValueRule> get added to a "deny list".

4. At the end of filtering, the final results are calculated by:

   1. Populating the result initially from the permit list.

   2. Removing all attribute values found in the deny list.

   3. Removing all attributes with no values.

In this way, it can be seen that a <DenyValueRule> 'trumps' the result of a <PermitValueRule> in the manner typically found in such policy languages.

...

<AttributeFilterPolicy id="example1">
  <PolicyRequirementRule xsi:type="Requester" value="https://sp.example.org" />
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="Value" value="jsmith" ignoreCasecaseSentitive="truefalse" />
  </AttributeRule>
</AttributeFilterPolicy>

...

<AttributeFilterPolicy id="example2">
  <PolicyRequirementRule  xsi:type="Value" value="jsmith" ignoreCasecaseSentitive="truefalse" />
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="Requester" value="https://sp.example.org" />
  </AttributeRule>
</AttributeFilterPolicy>

...

• The logic rules (and, or, not), which are natural PolicyRules have specific semantics when they are being used inside Matcher rules

• Some value-based rules change from being Matchers to being PolicyRules when the attributeId attribute is specified.
  So <...xsi:type="Value" value="jsmith" ignoreCasecaseSentitive="truefalse" /> is a Matcher (return all values which case-insensitively match "jsmith"), but <...xsi:type="Value" value="jsmith" ignoreCasecaseSentitive="truefalse" attributeId="uid" /> is a PolicyRule (true if and only if there is an attribute called "uid" with a value which case-insensitively matches jsmith).

...