MetadataConfiguration

File(s): conf/metadata-providers.xml
Format: Custom Schema

Overview

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.

Note that the other protocol(s) supported by the IdP generally support, but not strictly require, the use of SAML metadata, alongside other protocol-specific means of handling the same kinds of functions. Use of metadata enables a variety of useful configuration techniques that are superior to the features available from other approaches to managing relying parties and is generally advisable.

A typical use case is to load (and periodically reload) entity metadata from a local file:

<!--
    Load (and reload) entity metadata from a local file.

    The metadata refresh process is determined by the configured values of the 
    minRefreshDelay attribute (default: PT30S) and maxRefreshDelay attribute 
    (default: PT4H). If you want to load (or reload) the metadata immediately, 
    restart the IdP.
-->
<MetadataProvider id="LocalEntityMetadata" xsi:type="FilesystemMetadataProvider"
                  metadataFile="%{idp.home}/metadata/local-metadata.xml"/>

Another use case is to load (and periodically reload) a metadata aggregate from a remote source via HTTP:

<!--
    Load (and reload) a signed metadata aggregate from a remote HTTP server.

    This sample configuration assumes: (1) the top-level element of the XML 
    document is signed; (2) the top-level element of the XML document is 
    decorated with a validUntil attribute; (3) the validity interval is two 
    weeks (P14D) in duration; and (4) the server supports HTTP conditional GET.

    The metadata refresh process is influenced by the configured values of 
    the minRefreshDelay attribute (default: PT30S) and the maxRefreshDelay 
    attribute (default: PT4H) and also by any cacheDuration and validUntil 
    attributes in the metadata itself. If the server does not support HTTP 
    conditional GET, the attributes should be adjusted accordingly.
-->
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                  backingFile="%{idp.home}/metadata/federation-metadata-copy.xml"
                  metadataURL="http://example.org/metadata/federation-metadata.xml">

    <!--
        Verify the signature on the root element of the metadata aggregate 
        using a trusted metadata signing certificate.
    -->
    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
		certificateFile="%{idp.home}/conf/metadata/md-cert.pem"/>

    <!--
        Require a validUntil XML attribute on the root element and
        make sure its value is no more than 14 days into the future.
    -->
    <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D"/>

    <!-- Consume all SP metadata in the aggregate -->
    <MetadataFilter xsi:type="EntityRole">
        <RetainedRole>md:SPSSODescriptor</RetainedRole>
    </MetadataFilter>       

</MetadataProvider>

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.

Namespaces and Schemas

Nearly all elements described in this page and its children are defined in the urn:mace:shibboleth:2.0:metadata namespace, the schema for which can be located at http://shibboleth.net/schema/idp/shibboleth-metadata.xsd. Throughout this document and its children, this is assumed to be the default XML namespace in effect. The namespace prefix "metadata:" is conventionally also bound to this namespace.

The namespace prefix "security:" is used to refer to the urn:mace:shibboleth:2.0:security namespace, the schema for which can be located at http://shibboleth.net/schema/idp/shibboleth-security.xsd, and is generally used only in advanced scenarios or for compatibility.

The namespace prefixes "samlmd:" and "md:" are used to refer to the urn:oasis:names:tc:SAML:2.0:metadata namespace, the schema for which can be located at http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd

MetadataProvider Types

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.

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.

Miscellany