The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

The <AttributeFilterScript> element contains a script (or a reference to a script) that ultimately applies an implementation of Predicate<Attribute> to a given entity attribute.

Software version requirement

This feature requires IdP V3.4 or later.

The <AttributeFilterScript> element implicitly iterates over all entity attributes in the metadata pipeline. For each entity attribute, the entity attribute is removed from the input stream if (and only if) the predicate evaluates to false.

Schema

The <AttributeFilterScript> 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:

Name

Type

Use

Default

Description

language          
stringoptional"javascript"Defines the JSR-223 language to use. The default is ECMAScript using either the Rhino (Java 7) or Nashorn (Java 8) engines.

customObjectRef 3.2

stringoptional
The ID of a Spring bean defined elsewhere in the configuration.

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:

NameCardinalityDescription
<Script>


Exactly One

An inline script
<ScriptFile>
Path to a local file or classpath resource containing the script

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.

Always wrap inline scripts with a CDATA section

Always wrap inline scripts with a CDATA section, even if the script contains no special XML characters. This will future-proof your script.

Script Context

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

If the customObjectRef attribute is present on the <AttributeFilterScript> 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 <AttributeFilterScript> element, the script operates on a single input argument. The following trivial implementation of Predicate<Attribute> always returns false regardless of the input argument:

A trivial implementation of Predicate<Attribute>
<ConditionScript>
    <Script>
    <![CDATA[
        "use strict";

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

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

  • No labels