...
The Shibboleth IdP generally requires SAML metadata to provision connectivity with SAML relying parties and inform it about their capabilities and technical specifics. While you have the option to operate in a more "promiscuous" way (by enabling profiles for "unverified" RPs), this is not a common operating mode. In most cases, you will configure metadata sources in order to use the IdP's SAML features; this is done by adding <MetadataProvider>
elements inside the metadata-providers.xml file.
...
A typical use case is to load (and periodically reload) entity metadata from a local file:
Include Page | ||||
---|---|---|---|---|
|
Another use case is to load (and periodically reload) a metadata aggregate from a remote source via HTTP:
Include Page | ||||
---|---|---|---|---|
|
But increasingly, the dynamic providers (LocalDynamicMetadataProvider
and DynamicHTTPMetadataProvider
) are used in lieu of the reloading providers (FilesystemMetadataProvider
and FileBackedHTTPMetadataProvider
) shown above. See the MetadataManagementBestPractices topic for use cases and recommendations.
The ChainingMetadataProvider is often used to combine two or more metadata sources. The metadata-providers.xml file that ships with the software includes such a chain "wrapper" by default.
...
The precise behavior of any <MetadataProvider>
element is controlled by the xsi:type
attribute (see below). The following types are supported and examples are provided for each type. If the urn:mace:shibboleth:2.0:metadata
namespace is not the default, then a prefix (presumably "metadata:") is required when specifying these types.
xsi:type | Function |
---|---|
A container for an ordered sequence of metadata providers of any type | |
A dynamic provider that fetches metadata just-in-time from a suitably configured HTTP server | |
A dynamic provider that fetches metadata just-in-time from a local source such as a filesystem directory | |
A reloading provider that loads (and reloads) a metadata file from the filesystem in a background thread | |
A reloading provider that loads (and reloads) a metadata file from an HTTP server in a background thread | |
A reloading provider that loads (and reloads) a metadata file from a more complex resource type (in a background thread) | |
A provider that allows metadata to be specified inline |
Reference
Configuration options common to two or more metadata providers are listed in the subsections below. Others are specific to the xsi:type
, and these are documented on the pages specific to each type.
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
...
Expand | ||
---|---|---|
| ||
As described in the ReloadableServices documentation, the configuration is actually loaded from a bean whose name is specified by the property idp.service.metadata.resources, with the default value shibboleth.MetadataResolverResources (in turn defined in conf/services.xml to be a list with one entry: the file metadata-providers.xml) You can, if you choose, override this with additional or different files or more advanced sources. Each resource usually is expected to supply a "top level" It is also now possible to declare "by reference" metadata filters that are attached by reference, so it is possible to supply a resource whose top-level element is such a <MetadataFilter> in such cases. |
Expand | ||
---|---|---|
| ||
If a specific relying party (as identified by a specific entityID) is duplicated in the metadata sources provided, then which precise entry is chosen is governed by the following rules:
|