Page Comparison

In a nutshell, current best practices for the management of SAML metadata include the following specific recommendations:

1. Use FilesystemMetadataProvider or LocalDynamicMetadataProvider for local metadata

2. Use FileBackedHTTPMetadataProvider or DynamicHTTPMetadataProvider for remote metadata

3. Use entity attributes to drive automated relying party configuration (this is called a metadata-driven configuration)

...

The following sections expand on these best practices from the perspective of an IdP deployer.

Contents

Local Metadata

From an IdP perspective, the term local metadata refers to SP metadata under direct control of the IdP operator. More often than not, local metadata is sourced via email or downloaded from a partner web site by clicking a link on a protected web page. Typically local metadata does not expire. Metadata with an expiration date must be refreshed, whereas local metadata is a static resource by definition.

...

1. Load metadata in a background thread (using FilesystemMetadataProvider )

2. Load metadata just-in-time as needed (using LocalDynamicMetadataProvider )

FilesystemMetadataProvider

Perhaps the simplest way to manage local metadata is to configure one or more metadata providers of type FilesystemMetadataProvider . As its name implies, a FilesystemMetadataProvider loads (and periodically reloads) metadata from the file system. It does this in a background thread, so that the load operation is invisible to the end user. A simple example follows:

See the FilesystemMetadataProvider topic topic for more information.

For IdP deployments with few SP partners, using FilesystemMetadataProvider for local metadata is simple and straightforward. However, since each metadata provider must be configured separately, eventually this approach becomes unmanageable. A more scalable approach leverages a single LocalDynamicMetadataProvider as discussed in the next section.

LocalDynamicMetadataProvider

Using a LocalDynamicMetadataProvider , local metadata is made available to the IdP by simply dropping an entity descriptor into a system directory called the sourceDirectory. Unlike FilesystemMetadataProvider , no system restart is required when a file is added to (or removed from) the sourceDirectory. A LocalDynamicMetadataProvider dynamically resolves metadata from the sourceDirectory based on the entityID.

There is, however, some administrative overhead associated with a LocalDynamicMetadataProvider . First, the files in the sourceDirectory must be kept current. In particular, existing files must be updated or removed. Second, and more importantly, the files in the sourceDirectory must be suitably named so that the provider can easily resolve entity metadata as needed. These file operations require tools, either command-line tools or a GUI, neither of which is included with the Shibboleth IdP software.

See the the LocalDynamicMetadataProvider topic   topic for more information.

Remote Metadata

Remote metadata is loaded from a remote source via an HTTP metadata provider. There are two basic approaches:

1. Out-of-band metadata refresh (using FileBackedHTTPMetadataProvider)

2. In-band metadata query (

   using 

   using DynamicHTTPMetadataProvider )

Metadata refresh and metadata query are commonly used to consume metadata published by a trusted third party called a Federation. There are more than 50 recognized Federations in the R&E sector worldwide. Consult the eduGAIN technical site for an up-to-date list.

SAML metadata contains the public keys of federation partners, and so the distribution of metadata constitutes a public key infrastructure (PKI) for SAML deployments.

To obtain the latest set of trusted public keys, metadata must be kept current. To encourage reloading, remote metadata has an expiration date (@validUntil) and/or a cache directive (@cacheDuration). The latter is merely a hint but metadata expiration is absolute, so monitor your remote sources carefully.

FileBackedHTTPMetadataProvider

...

A typical use case involves a signed metadata aggregate (<md:EntitiesDescriptor>) published by a Federation. In this section, we show how to use a metadata provider of type FileBackedHTTPMetadataProvider to to load the aggregate.

For illustration, let's assume that: (1) the top-level <md:EntitiesDescriptor> element  element of the XML document is signed; (2) the top-level <md:EntitiesDescriptor> element  element of the XML document is decorated with a validUntil attribute; (3) the validity interval is two weeks (P14D) in duration; and (4) the server supports HTTP conditional GET. The sample metadata provider shown below retrieves the metadata, verifies the signature, and checks the expiration date before loading the metadata into IdP memory:

See the FileBackedHTTPMetadataProvider topic topic for more information.

Metadata aggregates may be arbitrarily large. Although the FileBackedHTTPMetadataProvider loads loads metadata in the background, parsed metadata objects are stored in memory for efficiency. Therefore sufficient memory must be available to accommodate the entire aggregate. Obviously, a large aggregate will have significant memory requirements.  A more efficient approach leverages a DynamicHTTPMetadataProvider as discussed in the next section.

DynamicHTTPMetadataProvider

In contrast to FileBackedHTTPMetadataProvider , a DynamicHTTPMetadataProvider fetches entity metadata just-in-time from a remote HTTP server. Since the provider loads only the metadata that is actually needed, the space requirements of a DynamicHTTPMetadataProvider are optimal. OTOH, since dynamic metadata query occurs in-band, the SAML protocol exchange is blocked until metadata is successfully retrieved from the query server and processed by the IdP.

An instance of DynamicHTTPMetadataProvider essentially essentially maps an entityID to a request URL based on a profile such as the SAML Profile for the Metadata Query Protocol, which itself is based on the more general Metadata Query Protocol specification. When queried, the server returns entity metadata (<md:EntityDescriptor>) for the entityID encoded in the request URL.

For illustration, let's assume that: (1) the top-level <md:EntityDescriptor> element of the XML document is signed; (2) the top-level <md:EntityDescriptor> element of the XML document is decorated with a validUntil attribute; (3) the validity interval is two weeks (P14D) in duration; and (4) the server conforms to the Metadata Query Protocol specification. The sample metadata provider shown below retrieves the metadata, verifies the signature, and checks the expiration date before loading the metadata into IdP memory:

See the DynamicHTTPMetadataProvider topic for more information.

...

The following table refers to some of the more common entity attributes. For more information, search the wiki on the @Name suffix shown in the table (which is also the corresponding Spring Java bean property name).

The following examples briefly illustrate the technique. See the MetadataDrivenConfiguration topic for numerous additional examples.

...

Suppose you want to integrate with an SP that does not support the SHA-2 family of digest methods typically used by default with XML signature. To enable SHA-1 for that particular SP, add this entity attribute to its metadata before dropping it into the sourceDirectory:

...

Add an entity attribute to local metadata

<md:Extensions>
 <mdattr:EntityAttributes>
   <saml:Attribute Name="http://shibboleth.net/ns/profiles/securityConfiguration" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
     <saml:AttributeValue>shibboleth.SecurityConfiguration.SHA1</saml:AttributeValue>
   </saml:Attribute>
 </mdattr:EntityAttributes>
</md:Extensions>

...

Suppose SP metadata is published in a remote metadata source (such as Federation metadata). It may turn out that the SP does not fully support XML encryption despite the fact that its published metadata includes an encryption certificate. To disable encryption for that particular SP, add the following child element to the relevant HTTP metadata provider:

...

Add an entity attribute to remote metadata

<MetadataFilter xsi:type="EntityAttributes">
 <saml:Attribute Name="http://shibboleth.net/ns/profiles/encryptAssertions" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
   <saml:AttributeValue xsi:type="xsd:boolean">false</saml:AttributeValue>
 </saml:Attribute>
 <Entity>https://sp.example1.org</Entity>
 <Entity>https://sp.example2.org</Entity>
 <Entity>https://sp.example3.org</Entity>
</MetadataFilter>

...