ConditionScript

The <ConditionScript> element contains a script (or a reference to a script) that ultimately applies an implementation of Predicate<EntityDescriptor> to a given entity descriptor.

The <ConditionScript> element implicitly iterates over all entity descriptors in the metadata pipeline. For each entity descriptor, the parent <MetadataFilter> element acts on the input entity descriptor if (and only if) the predicate evaluates to true. The action taken depends on the type of metadata filter.

The <ConditionScript> may be a child of the following filters:

• PredicateMetadataFilter
• NameIDFormatFilter
• EntityAttributesFilter

Schema

The <ConditionScript> element is a configuration element of type ScriptType. Both the element and its type are defined by the urn:mace:shibboleth:2.0:metadata schema, which can be located at http://shibboleth.net/schema/idp/shibboleth-metadata.xsd.

The following sections describe the attributes and elements of the ScriptType type.

Attributes

An element of type ScriptType has the following XML attributes:

language          

If the customObjectRef attribute is present, the result of the referenced Spring bean is made available to the script in a variable named custom. This is in addition to the normal script context discussed below.

Child Elements

An element of type ScriptType has the following child elements:

<Script>

<ScriptFile>

The script may be stored in a local file (with <ScriptFile>) or written inline (with <Script>). An inline script should be wrapped with a CDATA section to prevent interpretation of any special XML characters that may be included in the script.

Script Context

A script contained by a <ConditionScript> element has access to an object called input by convention. The actual input argument is an instance of a class that implements the EntityDescriptor interface.

If the customObjectRef attribute is present on the <ConditionScript> element, the result of the referenced Spring bean is made available to the script via a second object called custom. The type of the custom object is determined by the Spring bean.

Examples

If the customObjectRef attribute is not present on the <ConditionScript> element, the script operates on a single input argument. The following trivial implementation of Predicate<EntityDescriptor> always returns false regardless of the input argument:

<ConditionScript>
    <Script>
    <![CDATA[
        "use strict";

        // A trivial implementation of Predicate<EntityDescriptor>
        // applied to the input argument
        //
        // The input argument is of type:
        // org.opensaml.saml.saml2.metadata.EntityDescriptor
        //
        (function (entity) { return false; }(input));
    ]]>
    </Script>
</ConditionScript>

The formal parameter name is arbitrary. In the previous example, the parameter name entity is used for clarity. A nontrivial script would depend on the formal parameter entity.

If the customObjectRef attribute is present on the <ConditionScript> element, the script operates on a pair of arguments called custom and input. The following script implements a function that always returns the same trivial implementation of Predicate<EntityDescriptor> regardless of the custom argument. The resulting predicate is then applied to the input argument, which always returns false.

<ConditionScript customObjectRef="BeanID">
    <Script>
    <![CDATA[
        "use strict";

        // A trivial implementation of Function<T, Predicate<EntityDescriptor>>,
        // that is, a function that takes an argument of some unspecified type T
        // and returns an implementation of Predicate<EntityDescriptor>.
        // The latter is ultimately applied to the input object.
        //
        // The type of the custom argument depends on the application.
        //
        // The input argument is of type:
        // org.opensaml.saml.saml2.metadata.EntityDescriptor
        //
        (function (t) { return function (entity) { return false; }; }(custom))(input);
    ]]>
    </Script>
</ConditionScript>

Note that both formal parameter names (t and entity) are arbitrary. A nontrivial script would presumably substitute a more meaningful name for the formal parameter t.