The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
EntityAttributesFilter
Namespace: urn:mace:shibboleth:2.0:metadata
Schema: http://shibboleth.net/schema/idp/shibboleth-metadata.xsd
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 |
---|---|
<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 |
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 |
---|---|
<saml:Attribute> | An attribute which is added to all the entities which match any of the following |
<Entity> | The textual content is an entityID. All preceding attributes are added to the matching entity. |
<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. |
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"
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.
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.