Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Namespace:urn:mace:shibboleth:2.0:metadata
Schema:http://shibboleth.net/schema/idp/shibboleth-metadata.xsd

Table of Contents

Overview

...

To use the EntityAttributes filter, sequences of <saml:Attribute> elements are supplied as filter content. When a child element such as <Entity> or <ConditionRef> or <ConditionScript> evaluates to true, the SAML attributes are applied to the corresponding entities as entity attributes. The software automatically adds or removes the parent <mdattr:EntityAttributes> extension element as needed.

Note

Filter order is important!

This filter changes the content of the metadata and so a filter of type EntityAttributes should appear after any SignatureValidationFilter in the overall sequence of filters.

Tip

Position the EntityAttributes filter for efficiency

Deliberately position an EntityAttributes filter in the overall sequence of filters for optimal efficiency. In particular, a filter of type EntityAttributes should appear after the EntityRoleFilter since the latter effectively removes entities from the input.

...

SAML Attribute elements typically must be embedded in the configuration of the filter. The examples in this topic illustrate the most advisable approach.

Reference

XML Elements

The first two are optional, mutually exclusive, and must appear first:

Name

Description

<AttributeFilterRef>

Optional Bean ID of type Predicate<Attribute>, this is applied to all pre-existing extension attributes and any for which it evaluates false are removed prior to subsequent additions

<AttributeFilterScript>

The content of this element is an inline or local script resource that implements Predicate<Attribute>, which is applied to all pre-existing extension attributes. Any entity attribute for which it evaluates false are removed prior to subsequent additions.

Then, any of the following can be supplied in any order:

...

Add entity attributes to metadata

The following example adds the entity attribute "https://sp.example.org/tagname1" to entity "https://sp1.example.org", and both "https://sp.example.org/tagname1" and "https://sp.example.org/tagname2" to entity "https://sp2.example.org"

...

Expand
titleRemove unauthorized entity attributes from metadata
Code Block
languagexml
<MetadataFilter xsi:type="EntityAttributes">

    <!-- remove unauthorized entity attributes -->
    <AttributeFilterScript>
        <Script>
        <![CDATA[
            // an implementation of Predicate<Attribute>
            //
            // if the name of the entity attribute starts with
            // a common prefix of the set of Shibboleth profile
            // URIs, the function returns false, which removes
            // the entity attribute from its entity descriptor
            //
            // the input argument is of type:
            // org.opensaml.saml.saml2.core.Attribute
            //
            (function (attribute) {
                "use strict";

                // Shibboleth profile URI prefix
                var prefix = "http://shibboleth.net/ns/profiles";

                // check the parameter
                if (attribute === null) { return true; }

                // check a prefix of the attribute name
                return ! attribute.getName().startsWith(prefix);
            }(input));
        ]]>
        </Script>
    </AttributeFilterScript>

</MetadataFilter>
Note

Protect your metadata-driven configuration

An IdP that configures itself on-the-fly using entity attributes should include the previous filter in the overall sequence of filters. The previous filter should appear before any entity attributes are added by subsequent filters. On the other hand, if the metadata source is completely trustworthy (e.g., a local metadata source), the previous filter is not necessary. See the MetadataDrivenConfiguration topic for more info.

...