The Shibboleth IdP V4 software will leave support on September 1, 2024.
MetadataManagementBestPractices
In a nutshell, current best practices for the management of SAML metadata include the following specific recommendations:
Use https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 or https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 for local metadata
Use https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639 or https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631638 for remote metadata
Use entity attributes to drive automated relying party configuration (this is called a metadata-driven configuration)
In addition, consider using one or more MetadataFilter plugins to secure or optimize your configuration; for example the SchemaValidationFilter to ensure your metadata has no obvious errors in it, or the EntityRoleFilter to decrease the memory use of the loaded metadata.
The following sections expand on these best practices from the perspective of an IdP deployer.
Contents
Local Metadata
From an IdP perspective, the term local metadata refers to SP metadata under direct control of the IdP operator. More often than not, local metadata is sourced via email or downloaded from a partner web site by clicking a link on a protected web page. Typically local metadata does not expire. Metadata with an expiration date must be refreshed, whereas local metadata is a static resource by definition.
There are two basic approaches to local metadata management:
Load metadata in a background thread (using https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 )
Load metadata just-in-time as needed (using https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 )
Store the primary source files off-IdP
Although metadata is retrieved from the local IdP filesystem, the primary source files need not be stored on the IdP itself. The files can be stored elsewhere and then pushed to the IdP as needed. Command-line tools such as rcp or rsync work well for this purpose.
FilesystemMetadataProvider
Perhaps the simplest way to manage local metadata is to configure one or more metadata providers of type https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 . As its name implies, a https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 loads (and periodically reloads) metadata from the file system. It does this in a background thread, so that the load operation is invisible to the end user. A simple example follows:
See the https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 topic for more information.
For IdP deployments with few SP partners, using https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 for local metadata is simple and straightforward. However, since each metadata provider must be configured separately, eventually this approach becomes unmanageable. A more scalable approach leverages a single https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 as discussed in the next section.
LocalDynamicMetadataProvider
Using a https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 , local metadata is made available to the IdP by simply dropping an entity descriptor into a system directory called the sourceDirectory. Unlike https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 , no system restart is required when a file is added to (or removed from) the sourceDirectory. A https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 dynamically resolves metadata from the sourceDirectory based on the entityID.
There is, however, some administrative overhead associated with a https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 . First, the files in the sourceDirectory must be kept current. In particular, existing files must be updated or removed. Second, and more importantly, the files in the sourceDirectory must be suitably named so that the provider can easily resolve entity metadata as needed. These file operations require tools, either command-line tools or a GUI, neither of which is included with the Shibboleth IdP software.
See the https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 topic for more information.
Commit the metadata files to a source repository
Whether you use https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631640 or https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631642 , commit the metadata source files to a source repository (such as GitHub). This maintains a history of local metadata and encourages collaborative efforts among multiple system administrators.
Remote Metadata
Remote metadata is loaded from a remote source via an HTTP metadata provider. There are two basic approaches:
Out-of-band metadata refresh (using https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639)
In-band metadata query (using https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631638 )
Metadata refresh and metadata query are commonly used to consume metadata published by a trusted third party called a Federation. There are more than 50 recognized Federations in the R&E sector worldwide. Consult the eduGAIN technical site for an up-to-date list.
Join a Federation
Join a Federation that fully participates in eduGAIN. When you register your IdP metadata, it is distributed worldwide via the eduGAIN network, which optimizes interoperability.
SAML metadata contains the public keys of federation partners, and so the distribution of metadata constitutes a public key infrastructure (PKI) for SAML deployments.
Trust your metadata sources!
Remote metadata must be trusted. Do not blindly load remote metadata from untrusted sources. See the TrustManagement topic for more information, especially the section on Metadata Distribution and Verification.
To obtain the latest set of trusted public keys, metadata must be kept current. To encourage reloading, remote metadata has an expiration date (@validUntil) and/or a cache directive (@cacheDuration). The latter is merely a hint but metadata expiration is absolute, so monitor your remote sources carefully.
Ensure remote metadata does not expire!
By default, metadata that exceeds its expiration date will not be loaded by the Shibboleth metadata resolver.
FileBackedHTTPMetadataProvider
A https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639 will load (and periodically reload) a metadata file from an HTTP server in the background. The metadata file may contain a single entity (<md:EntityDescriptor>) or multiple entities (<md:EntitiesDescriptor>). The latter is more common.
A typical use case involves a signed metadata aggregate (<md:EntitiesDescriptor>) published by a Federation. In this section, we show how to use a metadata provider of type https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639 to load the aggregate.
Consult your federation operator
Ask your federation operator how best to configure a metadata provider of type FileBackedHTTPMetadataProvider. First determine the HTTP location of the metadata file, Then ask about the recommended values of the minRefreshDelay attribute (default: PT30S) and the maxRefreshDelay attribute (default: PT4H).
For illustration, let's assume that: (1) the top-level <md:EntitiesDescriptor> element of the XML document is signed; (2) the top-level <md:EntitiesDescriptor> 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 sample metadata provider shown below retrieves the metadata, verifies the signature, and checks the expiration date before loading the metadata into IdP memory:
See the https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639 topic for more information.
Metadata aggregates may be arbitrarily large. Although the https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639 loads metadata in the background, parsed metadata objects are stored in memory for efficiency. Therefore sufficient memory must be available to accommodate the entire aggregate. Obviously, a large aggregate will have significant memory requirements. A more efficient approach leverages a DynamicHTTPMetadataProvider as discussed in the next section.
DynamicHTTPMetadataProvider
In contrast to https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631639 , a https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631638 fetches entity metadata just-in-time from a remote HTTP server. Since the provider loads only the metadata that is actually needed, the space requirements of a DynamicHTTPMetadataProvider are optimal. OTOH, since dynamic metadata query occurs in-band, the SAML protocol exchange is blocked until metadata is successfully retrieved from the query server and processed by the IdP.
An instance of https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631638 essentially maps an entityID to a request URL based on a profile such as the SAML Profile for the Metadata Query Protocol, which itself is based on the more general Metadata Query Protocol specification. When queried, the server returns entity metadata (<md:EntityDescriptor>) for the entityID encoded in the request URL.
Consult your federation operator
Ask your federation operator how best to configure a metadata provider of type DynamicHTTPMetadataProvider. First determine the base URL of the MDQ server, Then ask about the recommended values of the minCacheDuration attribute (default: PT10M) and the maxCacheDuration attribute (default: PT8H). Finally, ask how best to configure the provider to mitigate the risk of an MDQ server that is unreachable or non-responsive.
For illustration, let's assume that: (1) the top-level <md:EntityDescriptor> element of the XML document is signed; (2) the top-level <md:EntityDescriptor> 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 conforms to the Metadata Query Protocol specification. The sample metadata provider shown below retrieves the metadata, verifies the signature, and checks the expiration date before loading the metadata into IdP memory:
See the DynamicHTTPMetadataProvider topic for more information.
Metadata-Driven Configuration
The goal of metadata-driven configuration is the ability to integrate with a new partner on the basis of metadata alone, preferably without touching the IdP configuration files. The first step towards achieving a 100% metadata-driven configuration is to configure a LocalDynamicMetadataProvider for local metadata. This is a one-time configuration. Thereafter, entity metadata is added to (or removed from) the sourceDirectory as described above. No additional configuration for local metadata is necessary.
The next step is to use entity attributes to drive special relying party configurations. The use of entity attributes is the hallmark of a metadata-driven configuration.
The following table refers to some of the more common entity attributes. For more information, search the wiki on the @Name suffix shown in the table (which is also the corresponding Spring Java bean property name).
@Name suffix | @xsi:type | Description |
|---|---|---|
assertionAudiences | One or more | |
defaultAuthenticationMethods | If the relying party does not ask for a particular | |
disallowedFeatures | A profile-specific bitmask of features to disallow | |
encryptAssertions | xsd:boolean | If set to false, the |
encryptNameIDs | xsd:boolean | If set to false, the |
includeConditionsNotBefore | xsd:boolean | If set to false, omit the |
nameIDFormatPrecedence | Override any | |
postAuthenticationFlows | Enable post-authn flows such as attribute consent and authorization checking | |
activationCondition | Enable profiles that are disabled by default (such as SAML1 SSO) | |
signAssertions | xsd:boolean | If true, sign assertions (often used in conjunction with |
signResponses | xsd:boolean | If false, do not sign responses (often used in conjunction with |
securityConfiguration |
| Configure a specific signing algorithm (e.g., enable SHA-1 on a per-RP basis) |
The following examples briefly illustrate the technique. See the MetadataDrivenConfiguration topic for numerous additional examples.
Entity Attributes and Local Metadata
Suppose you want to integrate with an SP that does not support the SHA-2 family of digest methods typically used by default with XML signature. To enable SHA-1 for that particular SP, add this entity attribute to its metadata before dropping it into the sourceDirectory:
Add an entity attribute to local metadata
<md:Extensions>
<mdattr:EntityAttributes>
<saml:Attribute Name="http://shibboleth.net/ns/profiles/securityConfiguration" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue>shibboleth.SecurityConfiguration.SHA1</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
</md:Extensions>Adding entity attributes to local metadata is straightforward since the IdP operator has complete control over the metadata. The next section shows how to add an entity attribute to remote metadata on-the-fly.
Entity Attributes and Remote Metadata
The following technique may be applied to any HTTP metadata provider (either a DynamicHTTPMetadataProvider or a FileBackedHTTPMetadataProvider).
Suppose SP metadata is published in a remote metadata source (such as Federation metadata). It may turn out that the SP does not fully support XML encryption despite the fact that its published metadata includes an encryption certificate. To disable encryption for that particular SP, add the following child element to the relevant HTTP metadata provider:
Add an entity attribute to remote metadata
<MetadataFilter xsi:type="EntityAttributes">
<saml:Attribute Name="http://shibboleth.net/ns/profiles/encryptAssertions" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xsd:boolean">false</saml:AttributeValue>
</saml:Attribute>
<Entity>https://sp.example1.org</Entity>
<Entity>https://sp.example2.org</Entity>
<Entity>https://sp.example3.org</Entity>
</MetadataFilter>The content of the <Entity> element is the entityID of the SP in question. Additional <Entity> elements may be specified, one for each SP that does not fully support XML encryption, as illustrated in the above example.