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.
Most of these beans, and probably some that are not mentioned, are defined in system/conf/utilities.xml
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.
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.
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.
None of these currently have "shorthand" bean names and so the full Java class names have to be used, but they are all stable API classes.
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.
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.
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.
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 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.