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.
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:
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.
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.
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.
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:
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.
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:
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).
One or more Audience values to add to the assertion (bug workaround)
If the relying party does not ask for a particular RequestedAuthnContext, attempt these login flow(s) in the order listed
A profile-specific bitmask of features to disallow
If set to false, the Assertion is not encrypted
If set to false, the NameID is not encrypted
If set to false, omit the NotBefore attribute on the assertion (bug workaround)
Override any <NameIDFormat> elements in metadata
Enable post-authn flows such as attribute consent and authorization checking
Enable profiles that are disabled by default (such as SAML1 SSO)
If true, sign assertions (often used in conjunction with signResponses)
If false, do not sign responses (often used in conjunction with signAssertions)
Configure a specific signing algorithm (e.g., enable SHA-1 on a per-RP basis)
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:
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:
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.