Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attribute Filtering occurs after most uses of the Attribute Resolution engine. It is about constraining the set of attributes and/or attribute values prior to them being used for some purpose, typically either for passing along to a relying party or less often to limit data passing into the IdP itself from another source. In this way, you can tailor the attributes seen by a specific relying party for a specific subject. The full range of environmental information, for instance about the relying party or (issuing party), about the specific request, and about the subject, is available to guide the filtering process.

Please note that filtering never changes or adds to the data, only limits it. The resolver manipulates data, not the filtering engine.

Tip

You can exercise and debug the behavior of this process for the most common case (release to a relying party) using the AACLI tool or the web interface it uses. This is particularly helpful if you're making changes, performing upgrades, etc., to validate the results match in any given case. At present, this is not supported for the "inbound" direction.

...

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

...

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
titleProperties

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.

...

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.

...

Code Block
languagexml
<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>

...

Code Block
languagexml
<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).

...