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.
shibboleth.Conditions.FALSE
- always return FALSE for any inputshibboleth.Conditions.TRUE
- always return TRUE for any inputshibboleth.Conditions.AND
- the result is the logical conjunction of two (similarly typed) Predicatesshibboleth.Conditions.OR
- the result is the logical disjunction of two (similarly typed) Predicatesshibboleth.Conditions.NOT
- the result is the logical negation of the provided predicateThe most important use of Predicates is in ActivationConditions, and the majority of the predefined beans are of this type. They implement Predicate<ProfileRequestContext>. In the role of ActivationConditions they are called with the current Request context.
shibboleth.Conditions.BrowserProfile
- return TRUE if the current profile is one which assumes browser interaction.shibboleth.Conditions.RelyingPartyId
- return TRUE based on the EntityID of the relying party,shibboleth.Conditions.Scripted
- return the value specified by a JSR-223 scriptshibboleth.Conditions.Expression
- return the value specified by an expression
shibboleth.Conditions.Predicate
shibboleth.Conditions.EntityDescriptor
shibboleth.Conditions.SubjectName
shibboleth.Conditions.AllowedSAMLPresenters
shibboleth.Conditions.IssuingDelegatedAssertion
These class of predicates default to being an ActivationCondition (although complex configuration allow this to be changed). Their task is to make a decision based on any 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 Predicates have names and so their FQ java class name has to be used.
net.shibboleth.idp.profile.logic.DateAttributePredicate
- returns TRUE if the content of the provided attribute parses to a date which is later that the current timenet.shibboleth.idp.profile.logic.SimpleAttributePredicate
- Matches the (all the) attributes' values against a lookup table (AttributeName, value)net.shibboleth.idp.profile.logic.RegexAttributePredicate
- applies a regularg expression against the values of a specified attibutenet.shibboleth.idp.profile.logic.DynamicAttributePredicate
These are not named beans, but the classes can be useful
net.shibboleth.idp.profile.logic.SimpleAttributePredicate
org.opensaml.profile.logic.IPRangePredicate
net.shibboleth.utilities.java.support.logic.StrategyIndirectedPredicate
net.shibboleth.ext.spring.util.SpringExpressionFunction
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
shibboleth.MessageContextLookup.Inbound
shibboleth.ContextFunctions.Scripted
shibboleth.ContextFunctions.Expression
shibboleth.MessageContextLookup.Inbound
shibboleth.MessageContextLookup.Outbound
shibboleth.MessageLookup.SAMLObject
shibboleth.MessageLookup.AuthnRequest
shibboleth.MessageContextLookup.Inbound
s
shibboleth.Pair
shibboleth.CommaDelimStringArray
shibboleth.NonFailFastValidator
shibboleth.HttpServletRequest
shibboleth.HttpServletResponse