A standard IdP configuration provides you with many "named beans" which are there to simplify configuration and to reduce the burden of remembering the specific class names. For ease of navigation, this topic divides them into three groups, Predicates (including ActivationConditions), Functions and other beans.
All Predicates beans are implementation of the Predicate interface, that is to say they are given a "thing" and return true or false.
The most important use of Predicates is in ActivationConditions, and the majority of the predefined beans are of type Predicate<ProfileRequestContext>. In the role of ActivationConditions they are called with the current ProfileRequestContext.
- return TRUE if the current profile is one which assumes browser interaction.
- return TRUE based on the entityID of the relying party
shibboleth.Conditions.Scripted - return the value specified by a JSR-223 script
shibboleth.Conditions.Expression - return the value specified by an expression
These predicates support decisions based on a subject's attributes that have been resolved (so far). 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.
None of these currently have "shorthand" names and so their FQ Java classname has to be used.
Other useful Predicate classes
These are not named beans, but the classes can be useful:
All Function beans are implementation of the Function interface, that is to say they are given a "thing" and return "some othre thing". Whilst this may sound of limited utili