The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.
ChainingMetadataProvider
The ChainingMetadataProvider
 is a container for an ordered sequence of metadata providers of any type. When searching for a particular entityID
, the metadata resolver consults each child provider in the order in which it is listed. See the parent topic for a detailed description of the search ordering algorithm used by the metadata resolver.
Schema Names and location
The <MetadataProvider>
 element and the type ChainingMetadataProvider
 are defined by the urn:mace:shibboleth:2.0:metadata
 schema, which can be located at http://shibboleth.net/schema/idp/shibboleth-metadata.xsd.
Attributes
The following attributes are required on a metadata provider of type ChainingMetadataProvider
:
Name | Type | Default | Description |
---|---|---|---|
id | String | required | Identifier for logging, identification for command line reload, etc. |
xsi:type | String | required | Must be set to "ChainingMetadataProvider" |
No other attributes are allowed.
Child Elements
A provider of type ChainingMetadataProvider
may contain any number of child providers:
Name | Cardinality | Description |
---|---|---|
<MetadataProvider > | 0 or more | An ordered sequence of metadata providers of any type (except the ChainingMetadataProvider  type) |
No other child elements are allowed.
Examples
Here is a brief summary of the examples in this section:
- Example 1: A traditional configuration usingÂ
FilesystemMetadataProvider
 for local metadata andÂFileBackedHTTPMetadataProvider
for federation metadata - Example 2: A "no touch" configuration using
LocalDynamicMetadataProvider
 for local metadata andÂFileBackedHTTPMetadataProvider
 for federation metadata - Example 3: A completely dynamic configuration usingÂ
LocalDynamicMetadataProvider
 for local metadata andDynamicHTTPMetadataProvider
 for federation metadata
The following example illustrates one or more providers of type FilesystemMetadataProvider
followed by a single FileBackedHTTPMetadataProvider
:
In the above example, local metadata is loaded before externally resolved federation metadata. This prevents federation metadata from accidentally overriding local metadata sources.
The following example is similar to the previous example except that multiple providers of type FilesystemMetadataProvider
have been replaced with a single LocalDynamicMetadataProvider
:
In the above example, all local metadata is handled by a single LocalDynamicMetadataProvider
. In this way, new local metadata may be added to the system without touching the configuration.
The following example is similar to the previous example except that the provider of type FileBackedHTTPMetadataProvider
 has been replaced with a DynamicHTTPMetadataProvider
:
In the above example, federation metadata is sourced as needed (i.e., dynamically). This avoids having to load a large metadata aggregate.
Avoid redundant providers in the chain
FileBackedHTTPMetadataProvider
 (Example #2) or a DynamicHTTPMetadataProvider
(Example #3) but not both. Assuming the same set of entities are represented in each case, the two approaches are mutually exclusive.