MappedEntityAttributePredicate

The predicate bean named shibboleth.Conditions.MappedEntityAttribute is a parent bean of type Predicate<EntityDescriptor> that evaluates a piece of metadata for the presence of specifically named <mdattr:EntityAttribute> extension “tags”. It allows one to build conditions based on the characteristics of an entity via their metadata, allowing more generic, cross-cutting conditions that don’t devolve into lists of SPs.

The IdP has built-in support for processing tags, and where possible automatically decoding and caching them in hashtables for ease of lookup. These data structures are complex but the predicate class handles that automatically and knows how to check for the decoded (“mapped”) tags.

There is a second variant called shibboleth.Conditions.EntityAttribute that searches the underlying metadata objects instead of the decoded, cached tag data. This is less efficient but has the advantage that the tags do not need to be decoded to find them. This is mostly useful because tags that do not carry the URI NameFormat will not be automatically decoded without dedicated transcoding rules defined in the registry, so if you don’t want to define the rules or use URI naming, this is an alternative.

Overview

Tags are an informal term for the attaching of <saml:Attribute> elements into a piece of metadata using a standard extension. Tags can express general, unconstrained information about an entity without having to define XML schema extensions specifically for every possible piece of information one wants to express.

Tags can be standardized for use in federation metadata provided by trusted third parties, or tags can be used in a purely local manner. Of course, it’s essential to ensure that local tags are never asserted by a third party and that federated tags are only applied under the proper conditions. Using URIs to name tags is essential for avoiding conflicts, as it is with all SAML Attributes.

Notably, this predicate takes an EntityDescriptor as input rather than a ProfileRequestContext, so it is usually used in conjunction with the EntityDescriptorPredicate adapter, as in the examples below.

This bean also requires use of another parent bean, shibboleth.TagCandidate, which represents a specific tag name and value(s) to check for. It is essentially the building block for the “rule(s)” to evaluate with the underlying predicate, i.e., it lays out what you want to check for in the metadata.

Semantics

The predicate takes as input a collection of candidates, i.e., beans inheriting from shibboleth.TagCandidate, to express the set of rules to evaluate. The rules can be combined in either an OR or AND fashion (checking for successful matches of one, or of all, candidates). Within each candidate bean, a tag is named and one or more values are provided to check for. Multiple values in this case are evaluated as an AND rule, requiring every value to match.

Examples

Single Tag/Value

Given a metadata excerpt:

The following defines a predicate that returns true. Note that in defining the tag candidate, the name of the tag is a constructor argument and the values are a property, so the Spring shortcut prefixes are different.

Single Tag, Either of Two Values

Given a metadata excerpt:

The following defines a predicate that returns true. Note that mutliple candidate beans are required in order to ensure that either matching will result in a true result. If the values were combined into a single candidate, each value would have to be in the metadata tag to match.