Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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 sourceDirectory XML attribute is also required, to identify the directory to load from.
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.
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
The type="LocalDynamic" attribute mustbe present.
The following attributes are supported for all MetadataProvider types:
Name
Type
Req?
Default
Description
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.
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
The following attribute MUST also be present:
Name
Type
Req?
Description
Name
Type
Req?
Description
sourceDirectory
string
Y
Specifies the directory to access for metadata
The following child elements are supported across all MetadataProvider types:
Not generally used, it provides an extension point to override the low-level handling of <ds:KeyInfo> elements and would be necessary to add support for some kind of custom XML key representation