In a nutshell, current best practices for the management of SAML metadata include the following specific recommendations:
...
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 As with FilesystemMetadataProvider, no system restart is required either 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, as 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 none of which is are included with the Shibboleth IdP software.
...
| Tip | ||
|---|---|---|
| ||
Whether you use FilesystemMetadataProvider or LocalDynamicMetadataProvider, commit the metadata source files to a source repository version control system (such as GitHubgit). This maintains a history of local metadata and encourages collaborative efforts among multiple system administrators. |
...
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 80 recognized Federations in the R&E sector worldwide. Consult the eduGAIN technical site for an up-to-date list.
| Tip | ||
|---|---|---|
| ||
| Join a Federation that fully participates in eduGAIN. When you register your IdP metadata, it is distributed worldwide via the eduGAIN network, which optimizes interoperability. |
...
A FileBackedHTTPMetadataProvider 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 as well as more practical as you can manage metadata for multiple Service Provider entities in a single file.
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 load the aggregate.
| Tip | ||
|---|---|---|
| ||
Ask your federation operator how best to configure a metadata provider of type FileBackedHTTPMetadataProvider. First get a trusted copy of the certificate or public key to use for signature validation of metadata, next determine the HTTP location of the metadata file, Thenthen ask about the recommended values of the minRefreshDelay attribute (default: PT30S) and the maxRefreshDelay attribute (default: PT4H). |
...
| Tip | ||
|---|---|---|
| ||
Ask your federation operator how best to configure a metadata provider of type |
...
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
The idea is to use entity attributes within the metadata to drive special relying party configurations. The use of entity attributes is the hallmark of a metadata-driven configuration.
...
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<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 (in which case you should of course notify the metadata producer, e.g. the Federation operator, and have them correct the metadata in question). To disable encryption for that particular SP, add the following child element to the relevant HTTP metadata provider:
...
The content of the <Entity> element is the entityID of the SP in question. Additional <Entity> elements may be specified, one for each SP from the parent metadata provider that does not fully support XML encryption, as illustrated in the above example.