Date: Thu, 28 Mar 2024 08:46:28 +0000 (UTC) Message-ID: <701587071.95.1711615588534@b61758e4c74a> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_94_1235218912.1711615588534" ------=_Part_94_1235218912.1711615588534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Namespace: urn:mace:shibboleth:2.0:metada=
ta
Schema: ht=
tp://shibboleth.net/schema/idp/shibboleth-metadata.xsd
The ChainingMetadataProvider
is a container for a=
n ordered sequence of metadata providers of any type. When conducting a sea=
rch, the metadata resolver consults each child provider in the order in whi=
ch it is listed. See the parent topic for a detailed description of the&nbs=
p;search =
ordering algorithm used by the metadata resolver.
Here is a brief summary of the examples in this section:
Example 1: A traditional configuration using FilesystemMetada=
taProvider
for local metadata and FileBackedHTTPMeta=
dataProvider
for federation metadata
Example 2: A "no touch" configuration using LocalDynamicMetad=
ataProvider
for local metadata and FileBackedHTTPMet=
adataProvider
for federation metadata
Example 3: A completely dynamic configuration using Loca=
lDynamicMetadataProvider
for local metadata and DynamicHT=
TPMetadataProvider
for federation metadata
The following example illustrates one or more providers of type FilesystemMetadataProvider
f=
ollowed by a single FileBa=
ckedHTTPMetadataProvider
:
Resolve federation metadata with either a FileBackedHTTPMetad=
ataProvider
(Example #2) or a DynamicHTTPMetadataPro=
vider
(Example #3) but not both. Assuming the same set of entities a=
re represented in each case, the two approaches are mutually exclusive.