...
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.
| Localtabgroupexpand |
|---|
| Localtab live |
|---|
|
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}).
The built-in properties which impact the filtering process (moreso just the filter service itself) are names staring with idp.service.attribute.filter as described here. localtab-live |
| Expand |
|---|
|
Name | Type | Description |
|---|
id | XML ID | Optional but recommended, unique ID for policy group used for logging purposes |
|
| Expand |
|---|
|
Name | Cardinality | Description |
|---|
<AttributeFilterPolicy> | 0 or more | A list of policies to apply |
|
Semantics
...
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.