The Shibboleth IdP generally requires SAML metadata to provision connectivity with 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 relatively rare. 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.
Contents
| Table of Contents |
|---|
In a typical A typical use case is to load (and default) configuration, only one resource is configured for metadata configuration, a file called metadata-providers.xml containing a "root" <MetadataProvider> element. This could make use of a single resource such as a periodically reload) entity metadata from a local file:
...
Another typical
| Include Page |
|---|
...
| language | xml |
|---|---|
| title | Simple file based configuration |
| collapse | true |
...
<MetadataProvider id="LocalMetadata" xsi:type="FilesystemMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
failFastInitialization="true"
metadataFile="%{idp.home}/metadata/my-metadata.xml"/>
|
Another use case is to load (and periodically reload) a metadata aggregate from a remote source via HTTP:
| Include Page | ||||
|---|---|---|---|---|
|
Alternatively, one can use a ChainingMetadataProvider, which combines two or more metadata sources. The metadata-providers.xml file that ships with the software declares such a chain "wrapper" by default.
...
You can, if you choose, override this with additional or different files or more advanced sources. Each resource must supply a "top level" <MetadataProvider> element with attributes and child elements as described above. Search order amongst multiple top level elements is arbitrated by the sortKey attribute, where lower values are processed before higher ones.
Anchor SearchOrdering SearchOrdering
Search Ordering
| SearchOrdering | |
| SearchOrdering |
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:
- Metadata sources combined via a chain are searched in the order in which they occur in the chain, and the first entry matching the entityID is returned.
If multiple "top level" Metadata Providers are provided then they are searched in an order derived from the (numeric) value of the
sortKeyattribute (lowest key first). If nosortKeyis specified, then the search order is undefined.- In whatever order of sources is in effect, the first entry matching the entityID is returned.
- If a single metadata source contains multiple entries with the same entityID, then which entry is returned is undefined (exception: invalid entries would be ignored in favor of valid ones in most cases).
V2 Compatibility
A single <MetadataProvider> element may be embedded in a legacy relying-party.xml file as described in the older documentation. Consult the V2 documentation for this, and do not mix and match this approach with newer configuration features.
During the V2 to V3 upgrade process, the original V2 relying-party.xml file is copied to metadata-providers.xml, to serve as the metadata configuration for the new version. It's strongly advisable after upgrading to update that file by stripping it of the older content and promote the <MetadataProvider> element in it to the root of the file. In the interim all other content in the file except for <MetadataProvider> elements (and any referenced <security:TrustEngine> elements) is ignored.
The following non-relevant trust engine types often found in a legacy relying-party.xml file are ignored if seen, and are not used for metadata verification (despite the confusing names):
ChainingMetadataExplicitKeyMetadataPKIXX509CredentialMetadataExplicitKeySignatureMetadataPKIXSignatureStaticPKIXX509Credential
New Capabilities in V3
The V3 metadata configuration syntax is backward-compatible with the V2 <MetadataProvider> syntax and adds some useful new shortcuts as well.
| Note | ||
|---|---|---|
| ||
| In anticipation of V4, a number of IdP features have been deprecated in V3. To ensure a seamless upgrade to V4, avoid the use of deprecated features in your V3 deployment. In particular, avoid any metadata-related features deprecated in V3. |
You can now provide multiple metadata configuration files (not just multiple metadata sources in one file), as described above.
A SignatureValidation filter need not contain a trustEngineRef attribute referencing a separately-defined trust engine; instead a certificate file may be specified directly with the certificateFile attribute. Alternatively, a PEM-format public key may be supplied inline via the <PublicKey> element.
| Note | ||
|---|---|---|
| ||
As a child element of the |