Versions Compared

Key

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

A filter of type EntityAttributes adds or removes SAML entity attributes to the <mdattr:EntityAttributes> extension element in metadata in order to drive software behavior based on entity attributes.

...

The embedded entity attribute is 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.

Attributes

None.

Child Elements

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

NameDescription
<AttributeFilterRef> 3.4

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

                                                       

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"

...

Note
titleProtect 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. OTOH, 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.

Code Block
languagexml
titleAdd entity attributes that affect signing operations
collapsetrue
<!-- 
    By default, responses are signed but assertions are not.
    This filter enables signing of both responses and assertions for select entities.
    For other entities, only assertions are signed.
-->
<MetadataFilter xsi:type="EntityAttributes">

    <!-- sign assertions -->
    <saml:Attribute Name="http://shibboleth.net/ns/profiles/saml2/sso/browser/signAssertions" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue xsi:type="xsd:boolean">true</saml:AttributeValue>
    </saml:Attribute>
  
    <!-- sign both responses and assertions for the following entity -->
    <Entity>https://sp.example1.org</Entity>
  
    <!-- do not sign responses -->
    <saml:Attribute Name="http://shibboleth.net/ns/profiles/saml2/sso/browser/signResponses" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue xsi:type="xsd:boolean">false</saml:AttributeValue>
    </saml:Attribute>
  
    <!-- sign assertions but do not sign responses for the following entities -->
    <Entity>https://sp.example2.org</Entity>
    <Entity>https://sp.example3.org</Entity>

</MetadataFilter>

...