...
Formally, this is the configuration of the "AttributeFilter" service. By default, one file, attribute-filter.xml, defines the attributes and values to be passed on. Multiple files can be specified by changing the bean referred to by the property idp.service.attribute.filter.resources (default value "shibboleth.AttributeFilterResources") defined in the services.xml file.
...
The bulk of the filter policy is contained in one or more <AttributeFilterPolicy> elements.
| Expand | ||
|---|---|---|
| ||
While not all that common, the attribute-filter.xml file can leverage property replacement to externalize particular settings. Properties are referenced via a brace syntax (e.g., %{idp.home}). |
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
| Expand | ||
|---|---|---|
| ||
| Anchor | ||||
|---|---|---|---|---|
|
...
Examines all the
<AttributeFilterPolicyGroup>elements provided (for instance across multiple files) in an unspecified order.Examines all the
<AttributeFilterPolicy>elements within each<AttributeFilterPolicyGroup>, again in an unspecified order.For each policy, if the
<PolicyRequirementRule>is true:Applies each of the child
<AttributeRule>elements, such that:The attributes (and their values) returned by
<PermitValueRule>get added to a "permit list".The attributes (and their values) returned by
<DenyValueRule>get added to a "deny list".
At the end of filtering, the final results are calculated by:
Populating the result initially from the permit list.
Removing all attribute values found in the deny list.
Removing all attributes with no values.
...
This is valid and has a specific meaning. But what is the meaning?
| Anchor | ||||
|---|---|---|---|---|
|
In order to make this tractable, the implementation considers plugin types as being either 'PolicyRules' or 'Matchers'. PolicyRules can be expected to give a "yes/no" answer and are usually used within a <PolicyRequirementRule>. Matchers usually return sets of values when applied to an attribute and are usually used within an <AttributeRule>.
...
So to answer the question above, the non-obvious second example means "If any value of any attribute matches 'jsmith' in a case-insensitive manner, then release all values of 'eduPersonPrincipalName' if the name of the SP is 'https://sp.example.org'". This is intelligible, but probably useless in practice. Most "swaps" of plugin types result in similar meaning.
Once compounded with NOT and deny rules, working out what is going on becomes incredibly non-intuitive. A good guiding rule is to only ever use PolicyRules inside <PolicyRequirementRule> and to only use Matchers inside <AttributeRule>.
Error Handling
Because of the dangers of the NOT plugin, it becomes impossible for any particular rule to "do the right thing" if a failure occurs during processing. The filtering engine handles this by special-casing errors to the fail-safe (release or accept nothing) case.