Versions Compared

Old Version 1

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version Current

changes.mady.by.user Scott Cantor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A typical use case is to load (and periodically reload) entity metadata from a local file:

Include Page
IDP5:FilesystemMetadataProviderExampleIDP5:
FilesystemMetadataProviderExample

Another use case is to load (and periodically reload) a metadata aggregate from a remote source via HTTP:

Include Page
IDP5:RemoteMetadataAggregateExampleIDP5:
RemoteMetadataAggregateExample

...

The precise behavior of any <MetadataProvider> element is controlled by the xsi:type attribute (see below). The following types are supported and examples are provided for each type. If the urn:mace:shibboleth:2.0:metadata namespace is not the default, then a prefix (presumably "metadata:") is required when specifying these types.

xsi:type

Function

ChainingMetadataProvider

A container for an ordered sequence of metadata providers of any type

DynamicHTTPMetadataProvider

A dynamic provider that fetches metadata just-in-time from a suitably configured HTTP server

LocalDynamicMetadataProvider

A dynamic provider that fetches metadata just-in-time from a local source such as a filesystem directory

FilesystemMetadataProvider

A reloading provider that loads (and reloads) a metadata file from the filesystem in a background thread

FileBackedHTTPMetadataProvider

A reloading provider that loads (and reloads) a metadata file from an HTTP server in a background thread

ResourceBackedMetadataProvider

A reloading provider that loads (and reloads) a metadata file from a more complex resource type (in a background thread)

InlineMetadataProvider

A provider that allows metadata to be specified inline

Reference

Configuration options common to two or more metadata providers are listed in the subsections below. Others are specific to the xsi:type, and these are documented on the pages specific to each type.

Expand
titleCommon XML Attributes
Include Page
IDP5:MetadataProviderCommonAttributesIDP5:
MetadataProviderCommonAttributes
Expand
titleReloading XML Attributes
Include Page
IDP5:MetadataProviderReloadingAttributesIDP5:
MetadataProviderReloadingAttributes
Expand
titleDynamic XML Attributes
Include Page
IDP5:MetadataProviderDynamicAttributesIDP5:
MetadataProviderDynamicAttributes
Expand
titleHTTP XML Attributes
Include Page
IDP5:MetadataProviderHTTPAttributesIDP5:
MetadataProviderHTTPAttributes
Expand
titleCommon XML Elements
Include Page
IDP5:MetadataProviderChildElementsIDP5:
MetadataProviderChildElements

...

Expand
titleMultiple Configuration FIles

As described in the ReloadableServices documentation, the configuration is actually loaded from a bean whose name is specified by the property idp.service.metadata.resources, with the default value shibboleth.MetadataResolverResources (in turn defined in conf/services.xml to be a list with one entry: the file metadata-providers.xml)

You can, if you choose, override this with additional or different files or more advanced sources. Each resource usually is expected to supply a "top level" <MetadataProvider> element with attributes and child elements as described above. Search order amongst multiple top level elements is arbitrated by the sortKey attribute, where lower values are processed before higher ones.

It is also now possible to declare "by reference" metadata filters that are attached by reference, so it is possible to supply a resource whose top-level element is such a <MetadataFilter> in such cases.

Expand
titleSearch Ordering

If a specific relying party (as identified by a specific entityID) is duplicated in the metadata sources provided, then which precise entry is chosen is governed by the following rules:

  • Metadata sources combined via a chain are searched in the order in which they occur in the chain, and the first entry matching the entityID is returned.

  • If multiple "top level" Metadata Providers are provided then they are searched in an order derived from the (numeric) value of the sortKey attribute (lowest key first). If no sortKey is specified, then the search order is undefined.

  • In whatever order of sources is in effect, the first entry matching the entityID is returned.

  • If a single metadata source contains multiple entries with the same entityID, then which entry is returned is undefined (exception: invalid entries would be ignored in favor of valid ones in most cases).