MetadataManagementBestPractices

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

1. Use FilesystemMetadataProvider or https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968 for local metadata

2. Use https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865 or https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506816 for remote metadata

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

In addition, consider using one or more MetadataFilter plugins to secure or optimize your configuration; for example the SchemaValidationFilter to ensure your metadata has no obvious errors in it, or the EntityRoleFilter to decrease the memory use of the loaded metadata.

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.

There are two basic approaches to local metadata management:

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

2. Load metadata just-in-time as needed (using https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968 )

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 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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968 as discussed in the next section.

LocalDynamicMetadataProvider

Using a https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968 , 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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968 dynamically resolves metadata from the sourceDirectory based on the entityID.

There is, however, some administrative overhead associated with a https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968 . 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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506968   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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865)

2. In-band metadata query (using https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506816 )

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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865 will load (and periodically reload) a metadata file from an HTTP server in the background. The metadata file may contain a single entity (<md:EntityDescriptor>) or multiple entities (<md:EntitiesDescriptor>). The latter is more common.

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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865 to load the aggregate.

For illustration, let's assume that: (1) the top-level <md:EntitiesDescriptor> element of the XML document is signed; (2) the top-level <md:EntitiesDescriptor> 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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865 topic for more information.

Metadata aggregates may be arbitrarily large. Although the https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865 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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506865 , a https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506816 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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199506816 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.

Metadata-Driven Configuration

The goal of metadata-driven configuration is the ability to integrate with a new partner on the basis of metadata alone, preferably without touching the IdP configuration files. The first step towards achieving a 100% metadata-driven configuration is to configure a LocalDynamicMetadataProvider for local metadata. This is a one-time configuration. Thereafter, entity metadata is added to (or removed from) the sourceDirectory as described above. No additional configuration for local metadata is necessary.

The next step is to use entity attributes to drive special relying party configurations. The use of entity attributes is the hallmark of a metadata-driven configuration.

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.

Entity Attributes and Local Metadata

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

Adding entity attributes to local metadata is straightforward since the IdP operator has complete control over the metadata. The next section shows how to add an entity attribute to remote metadata on-the-fly.

Entity Attributes and Remote Metadata

The following technique may be applied to any HTTP metadata provider (either a DynamicHTTPMetadataProvider or a FileBackedHTTPMetadataProvider).

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

The content of the <Entity> element is the entityID of the SP in question. Additional <Entity> elements may be specified, one for each SP that does not fully support XML encryption, as illustrated in the above example.