EntityAttributesFilter

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

1 Overview
- 1.1 A simple entity attribute
2 Other Relevant Schemas
3 Reference
- 3.1 XML Elements
4 Examples

Overview

A filter of type EntityAttributes adds or removes SAML entity attributes to or from metadata in order to drive software behavior. This filter is usually applied to an HTTP metadata provider such as the FileBackedHTTPMetadataProvider or the DynamicHTTPMetadataProvider, since locally maintained metadata is directly modifiable already.

The <mdattr:EntityAttributes> extension element is a container for entity attributes, sometimes referred to informally as "tags". "Tagging" an entity refers to attaching an entity attribute.

Syntactically, an entity attribute looks like an ordinary user attribute one might find in an assertion. For example:

A simple entity attribute

<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Attribute Name="http://macedir.org/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>http://refeds.org/category/research-and-scholarship</saml:AttributeValue>
    </saml:Attribute>
</mdattr:EntityAttributes>

In the previous example, the name and value of the entity attribute are http://macedir.org/entity-category and http://refeds.org/category/research-and-scholarship, respectively. Note that an entity attribute may be multi-valued.

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.

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.

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.

An inbound attribute filtering feature (<AttributeFilterRef> or <AttributeFilterScript>) allows pre-existing entity attributes to be removed prior to performing any additions. This allows locally applied tags to be blocked from use by external metadata sources, which prevents misuse.

Other Relevant Schemas

Unlike many features, configuring this filter typically requires supplying elements from other XML namespaces, so requires some working knowledge of editing XML and mixing namespaces.

The schema for the <mdattr:EntityAttributes> extension element that is produced by this filter is part of the OASIS SAML V2.0 Metadata Extension for Entity Attributes specification, though this isn't typically directly needed when configuring this filter.

The embedded entity attributes produced by the filter are defined by the urn:oasis:names:tc:SAML:2.0:assertion namespace, the schema for which can be located at http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd. The latter namespace is usually associated with the saml: prefix.

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

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:

Name	Description

Name	Description
<saml:Attribute>	An attribute which is added to all the entities which match any of the following `<Entity>` or `<ConditionRef>` elements
<Entity>	The textual content is an entityID. All preceding attributes are added to the matching entity.
<EntityRegex> ^5.1	The textual content is a regular expression to match against the entityID. All preceding attributes are added to matching entities.
<ConditionRef>	The textual content is the Bean ID of type Predicate<EntityDescriptor>. All preceding attributes are added to the entities for which this returns true.
<ConditionScript>	The content of this element is an inline or local script resource that implements Predicate<EntityDescriptor>. All preceding attributes are added to the entities for which this returns true.

Examples

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"

<MetadataFilter xsi:type="EntityAttributes" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Attribute Name="https://sp.example.org/tagname1">
        <saml:AttributeValue>foo</saml:AttributeValue>
    </saml:Attribute>
    <Entity>https://sp1.example.org</Entity>
    <saml:Attribute Name="https://sp.example.org/tagname2">
        <saml:AttributeValue>foo</saml:AttributeValue>
        <saml:AttributeValue>bar</saml:AttributeValue>
    </saml:Attribute>
    <Entity>https://sp2.example.org</Entity>
</MetadataFilter>

Remove entity attributes from metadata

The following example removes unauthorized entity attributes from the input. The metadata filter uses an <AttributeFilterScript> to remove any and all entity attributes that might be used to subsequently configure a SAML protocol at runtime. It does this by matching on a common prefix of the overall set of Shibboleth profile URIs.

<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>

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.

Add entity attributes that affect signing operations

The following example uses entity attributes to override default signing operations during web browser SSO.

Add an entity attribute that disables encryption

The following example uses an entity attribute to disable encryption on a specific set of entities in the input. A <ConditionScript> adds the entity attribute (encryptAssertions) to a collection of entities specified by a Spring bean (customObjectRef="MyEntityCollection") defined elsewhere in the configuration. The collection is exposed to the script via a custom object of type Collection<String>. Each element of the collection is an entityID.

The script takes an argument of type Collection<String> (i.e., the custom object) and returns a function that implements Predicate<EntityDescriptor>. The resulting predicate is applied to the input object. The entity attribute is added to the entity descriptor if (and only if) the predicate evaluates to true.