Overview
Identified by type="LocalDynamic", this MetadataProvider loads metadata on-demand from the local file system using a filename convention based on the SHA-1 hash of the entityID of the IdP.
The deployer is responsible for populating a directory with metadata files, and this may be done while the SP is in operation. New metadata will be seen automatically the first time it is requested after being added to the directory.
This plugin is optimized to track the last modification time of any metadata file it loads and skips unnecessary reprocessing if a file hasn't been modified, so it can be tuned for very frequent refresh attempts if desired, to minimize the time needed to apply changes.
Each file should contain exactly one <EntityDescriptor> and the name of the file should be the lowercase hex-encoded SHA-1 hash of the entityID within that metadata.
Example generating filename with OpenSSL
$ echo -n "https://idp.example.org/idp/shibboleth" | openssl sha1 1bec942a9ca29787c26924440ad4cb8208f9b9e4
Note that it is often unnecessary to apply filters such as signature or validity constraints to a local directory of metadata because it is typically curated by hand, but it is certainly possible to do so.
Reference
Attributes
The type="LocalDynamic" attribute must be present, and the following attribute must also be present:
Name | Type | Req? | Description |
|---|---|---|---|
sourceDirectory | string | Y | Specifies the directory to access for metadata |
The following attributes are supported for all MetadataProvider types:
Name | Type | Req? | Default | Description |
|---|---|---|---|---|
type | string | Y | Specifies the exact type of metadata plugin to use | |
id | string | A label for the metadata source, used in logging and status reporting | ||
validate | boolean | false | Whether the XML should be schema validated before it is parsed. Note that some sources of metadata (e.g., ADFS) may contain a large number of extensions. The SP now includes a number of additional schemas to make validation of such extensions possible, but there are always exceptions. |
The following attributes are supported only for the "dynamic" (on-demand) MetadataProvider types (MDQ, Dynamic, LocalDynamic):
Name | Type | Default | Description |
|---|---|---|---|
cleanupInterval | time in seconds | 1800 (30 mins) | Time in seconds between execution of background thread to scan for expired cached metadata and remove it from memory. You can set this to 0 to disable any cleanup, but this will potentially cause memory usage to grow. |
cleanupTimeout | time in seconds | 1800 (30 mins) | Extra time to leave recently-unused entries in the cache before the background cleanup process will remove them |
maxCacheDuration | time in seconds | 28800 (8 hours) | Upper bound on time before attempt to reload metadata for an entity |
minCacheDuration | time in seconds | 600 (10 mins) | Lower bound on time before attempt to reload metadata for an entity |
refreshDelayFactor | decimal | 0.75 | Factor applied to the metadata's own validity or caching period to determine the reload interval to use. Once applied, the result is bounded by the minCacheDuration and maxCacheDuration settings to determine the time of the next attempt. If reload attempts fail, the existing metadata (if any) will be reused until it actually expires |
negativeCache | boolean | see description | Controls whether lookup failures are cached (for the minCacheDuration). This can avoid repeatedly accessing a server which is failing or simply has no metadata. Defaults to "true" for remote dynamic metadata providers (MDQ, Dynamic) and "false" for the LocalDynamicProvider |
Child Elements
The following child elements are supported across all MetadataProvider types:
Name | Cardinality | Description |
|---|---|---|
any | Metadata filter plugins to run | |
<KeyInfoResolver> | 0 or 1 | Not generally used, it provides an extension point to override the low-level handling of |
Example
LocalDynamic Metadata Source
<MetadataProvider type="LocalDynamic" sourceDirectory="localDynamicDir"/>