MetadataManagementBestPractices

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)

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 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 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 LocalDynamicMetadataProvider   topic for more information.