PredefinedBeans

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.

Predicates

All Predicates beans are implementation of the Predicate interface, that is to say they are given a "thing" and return true or false.

Logic

• shibboleth.Conditions.FALSE - always return FALSE for any input
• shibboleth.Conditions.TRUE - always return TRUE for any input
• shibboleth.Conditions.AND - the result is the logical conjunction of two (similarly typed) Predicates
• shibboleth.Conditions.OR  - the result is the logical disjunction of two (similarly typed) Predicates
• shibboleth.Conditions.NOT - the result is the logical negation of the provided predicate

Activation

The 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 script
• shibboleth.Conditions.Expression - return the value specified by an expression 

• shibboleth.Conditions.Predicate
• shibboleth.Conditions.EntityDescriptor
• shibboleth.Conditions.SubjectName
• shibboleth.Conditions.AllowedSAMLPresenters
• shibboleth.Conditions.IssuingDelegatedAssertion


Attribute Predicates

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 time
  
• net.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 attibute
• net.shibboleth.idp.profile.logic.DynamicAttributePredicate 
  

Other useful Predicate classes

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


See Also

• ActivationConditions
• PredicateConfiguration
• PredicateMetadataFilter
  

Functions

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

Context Functions

• shibboleth.MessageContextLookup.Inbound
• shibboleth.ContextFunctions.Scripted
• shibboleth.ContextFunctions.Expression
• shibboleth.MessageContextLookup.Inbound
• shibboleth.MessageContextLookup.Outbound
• shibboleth.MessageLookup.SAMLObject
• shibboleth.MessageLookup.AuthnRequest

Other Functions

• shibboleth.MessageContextLookup.Inbound
• s

Other Beans

• shibboleth.Pair
• shibboleth.CommaDelimStringArray
• shibboleth.NonFailFastValidator
• shibboleth.HttpServletRequest
• shibboleth.HttpServletResponse
  

Alphabetic listing