The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.

PredefinedBeans

Owned by Scott Cantor
Last updated: May 16, 2023
6 min read

The IdP configuration provides many "named beans" to simplify configuration and to reduce the burden of knowing specific class names, particularly in cases where the class names may be subject to change in future major versions. Other classes may not have supporting beans but are part of the API and provide useful pre-built logic to use in configuring the system.

For ease of navigation, this topic divides them into three groups, Predicates (which can also generally be used in ActivationConditions), Functions, and other beans. These categories also include BiPredicates and BiFunctions, which are binary input variants of traditional unary interfaces that are occasionally needed.

Predicates

Predicate beans are implementation of the Java Predicate functional interface; they are applied to a "thing" and return true or false.

Logic

Profile Request Conditions

The most common use of Predicates is in ActivationConditions, and the majority of the predefined beans are of type Predicate<ProfileRequestContext>. Such conditions are called with the object at the root of the tree of contexts that makes up the state of a request, so they can be very generic, or implemented for very specific purposes.

Attribute Predicates

These predicates support decisions based on a subject's resolved attributes. All variants allow for either the filtered or unfiltered attributes to be consulted. Obviously these predicates are only valid after attribute resolution has taken place.

They generally assume the "normal" attribute resolution process; more specialized or deployer-triggered resolution processes (e.g., during authentication) will typically require additional customizations in order to locate the AttributeContext containing the data. As an example, using one of these predicates as an ActivationCondition guarding an AttributeDefinition or DataConnector will typically require the PreRequestedAttributes feature, and the use of the shibboleth.ChildLookup.PreRequestedAttributeContext lookup bean.

Prior to V4.3, none of these currently had "shorthand" bean names and so the full Java class names had to be used, but they are all stable API classes. V4.3 introduces new parent beans of the form shibboleth.Conditions.SimpleAttribute, shibboleth.Conditions.DateAttribute, etc. for future-proofing.

Other Predicates

These are also not named beans, but are useful classes:

BiPredicates 4.1

See Also

Functions

All Function beans are implementation of the Java Function functional interface; they are given a "thing" and return a "thing". The most common uses in the IdP are either for overriding how information is located, or to supply dynamically computed information to the IdP that might be based on local deployment customizations.

Use of Functions tends to be more varied than Predicate, but ProfileRequestContext is still the most common input type, with the output type obviously varying.

For a few unusual cases, there are also a set of BiFunction beans, which support two inputs instead of just one.

General Purpose

Context Functions

Context functions are a specialized subset of Function that operate on a particular "context class" from the hierarchy of objects that manage request state, often though not exclusively the ProfileRequestContext type. They return various pieces of data associated with the input context and act as navigation functions that provide access to the data being operated on.

The two generic extension points are:

A number of concrete, defined beans exist for looking up various bits of information directly, as part of more complex function composition or via scripting to avoid hard-wiring in particular expressions and to automate null checking to avoid exceptions. They generally return nulls if unable to return legitimate values.

RelyingParty-Based Context Functions

A subset of context functions rely first on locating a RelyingPartyContext, and then on to particular data. The default behavior of these functions is to locate a RelyingPartyContext as a direct child of the input ProfileRequestContext, which is overrideable using the relyingPartyContextLookupStrategy property of the bean to change the behavior.

Tag Lookup Functions 4.3

A set of function beans exists to extract metadata extension “tags”. See AccessingMetadataTags for details and examples.

Context Lookup Functions

Context lookup functons are another type of context function with the particular purpose of navigating around the context tree from one context type to another. Most of these unlinked beans are of type ChildContextLookup and return a child context of the associated type (or null).

The "ChildLookupOrCreate" variants will create contexts of the designated type in the event none exists, so a non-null input will never return a null in those cases. Any of the "ChildLookup" variants can be given creation semantics by deriving a new bean from the existing parent and adding c:createContext="true"

The reason these are somewhat willy-nilly is that the beans that exist are primarily the ones needed to drive the IdP's own code, but there are many others that could be defined in principle.

Consumers / BiConsumers 4.1

Consumers and BiConsumers are similar to Functions and BiFunctions except that they don't return a result but simply produce side effects against their input(s). They are not common, but appear in a few places in the API where side effects are needed but no exceptions are expected to be raised. A pair of beans are supplied to implement them more easily.

Other Beans

A few other beans of general utility are defined.