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.
MetadataManagementBestPractices
In a nutshell, current best practices for the management of SAML metadata include the following specific recommendations:
Use FilesystemMetadataProvider or LocalDynamicMetadataProvider for local metadata
Use FileBackedHTTPMetadataProvider or DynamicHTTPMetadataProvider for remote metadata
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:
Load metadata in a background thread (using FilesystemMetadataProvider )
Load metadata just-in-time as needed (using LocalDynamicMetadataProvider )
Store the primary source files off-IdP
Although metadata is retrieved from the local IdP filesystem, the primary source files need not be stored on the IdP itself. The files can be stored elsewhere and then pushed to the IdP as needed. Command-line tools such as rcp
or rsync
work well for this purpose.
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.
Commit the metadata files to a source repository
Whether you use FilesystemMetadataProvider or