Shibboleth and simpleSAMLphp are the only known SAML implementations that support dynamic metadata query.
Contents
If you know of some other metadata query client, please share on the metadata-support mailing list.
The following DynamicHTTPMetadataProvider works with Shibboleth IdP 3.2 (or later):
<MetadataProvider
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"
id="dynamicMDQ" xsi:type="DynamicHTTPMetadataProvider">
<!-- Verify the signature on the root element (i.e., the EntityDescriptor element) -->
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="${idp.home}/conf/metadata/mdq-beta-cert.pem" />
<!--
Require a validUntil XML attribute on the EntityDescriptor element
and make sure its value is no more than 14 days into the future
-->
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />
<!-- This MetadataProvider conforms to the Metadata Query Protocol -->
<MetadataQueryProtocol>http://mdq-beta.incommon.org/global</MetadataQueryProtocol>
</MetadataProvider>
|
If you find some other configuration that works better, please share your config details on the metadata-support mailing list.
The following Dynamic MetadataProvider works with Shibboleth SP 2.4 (or later):
<MetadataProvider type="Dynamic" ignoreTransport="true">
<!-- Substitute an URL-encoded entityID into the request URL -->
<Subst>http://mdq-beta.incommon.org/global/entities/$entityID</Subst>
<!--
Require a validUntil XML attribute on the EntityDescriptor element
and make sure its value is no more than 14 days into the future
-->
<MetadataFilter type="RequireValidUntil" maxValidityInterval="1209600"/>
<!-- Verify the signature on the metadata file -->
<MetadataFilter type="Signature" certificate="mdq-beta-cert.pem"/>
</MetadataProvider>
|
If your deployment exposes a dynamic discovery interface, the above metadata configuration is not sufficient. In that case, configure a Chaining MetadataProvider that falls back on an aggregate if necessary. The following configuration requires Shibboleth SP 2.4 (or later):
<!--
A chaining MetadataProvider that tries dynamic metadata query first,
and if that fails, the SP falls back on standard metadata refresh.
-->
<MetadataProvider type="Chaining">
<!-- Dynamic Metadata Query -->
<MetadataProvider type="Dynamic" ignoreTransport="true">
<!-- Substitute an URL-encoded entityID into the request URL -->
<Subst>http://mdq-beta.incommon.org/global/entities/$entityID</Subst>
<!-- Check the expiration date -->
<MetadataFilter type="RequireValidUntil" maxValidityInterval="1209600"/>
<!-- Verify the XML signature -->
<MetadataFilter type="Signature" certificate="mdq-beta-cert.pem"/>
</MetadataProvider>
<!-- Standard Metadata Refresh -->
<MetadataProvider type="XML"
url="http://mdq-beta.incommon.org/global/entities"
backingFilePath="BETA-InCommon-metadata.xml" maxRefreshDelay="3600">
<!-- Verify the XML signature on the aggregate -->
<MetadataFilter type="Signature" certificate="mdq-beta-cert.pem"/>
<!-- Check the expiration date -->
<MetadataFilter type="RequireValidUntil" maxValidityInterval="1209600"/>
<!-- Consume all IdP metadata in the aggregate -->
<MetadataFilter type="EntityRoleWhiteList">
<RetainedRole>md:IDPSSODescriptor</RetainedRole>
<RetainedRole>md:AttributeAuthorityDescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>
</MetadataProvider>
|
The above metadata configuration accommodates deployments that expose a dynamic discovery interface. To build the discovery interface, the SP falls back on aggregate metadata.
TBD