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 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)
Metadata providers are a key component; Shibboleth is a 100% metadata-driven SAML implementation and has no other means of provisioning relationships with IdPs. If you don't have metadata for an IdP you have to create it.
Like most plugins, the type attribute determines which type of plugin to use. Each type may support its own attributes and child elements, in addition to the Common Attributes and Common Elements listed below.
Note that when multiple providers are configured, the behavior is unspecified when an entityID is present in more than one provider/source. The specifics of what happens at present depend on whether there are differences between the metadata that could be relevant to what the SP is actually searching for, but in most cases the first one found will trump later instances. That is not guaranteed behavior, merely the current behavior.
Largely replaced by the LocalDynamic type, this batch-loads metadata from all the files contained in a specified directory
Reference
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 attributes are supported only for the remote dynamic MetadataProvider types (MDQ, Dynamic):
Name
Type
Default
Description
Name
Type
Default
Description
cacheDirectory
string
Defines a directory in which downloaded metadata will be cached. During startup the directory is also scanned and the metadata loaded to prime the in-memory cache. This directory should be unique for every metadata provider configured.
A relative path will be applied relative to the /var/cache/shibboleth root, and the directory will be created if it does not exist.
backgroundInitialize
boolean
true
Flag indicating whether the plugin should initialize itself from the cache in the background to improve startup time. It has no effect if cacheDirectory is unset.
verifyHost
boolean
true
If true, attempts to resolve metadata using a TLS-enabled URL will verify the hostname in the server's certificate against the expected hostname (but this is the extent of the validation performed unless other configuration is in place)
ignoreTransport
boolean
false
If true, authentication of the transport layer will be ignored when resolving metadata. If false, a <TrustEngine> child element must be specified.
Accept 3.1
string
"application/samlmetadata+xml"
Overrides the standard Accept header used to request the SAML metadata content type
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
The following child elements are supported by the remote, on-demand MetadataProvider types (MDQ, Dynamic):
A TrustEngine plugin to apply to a server's certificate when resolving metadata using a TLS-enabled URL.
This trust engine obviously cannot require the use of metadata to operate. If not supplied, the ignoreTransport attribute must be set to true to avoid a configuration error. This is done to prevent a misconfigured trust engine from resulting in insecure metadata resolution.