has been upgraded to Confluence 6.15.10. If you have any questions and/or concerns, please contact us at
Page tree
Skip to end of metadata
Go to start of metadata

Jump to: 

The InCommon metadata service employs a style of metadata distribution referred to as "per-entity metadata". This page explains what is per-entity metadata.

What is per-entity metadata?

Per-entity metadata allows your IdP or SP to consume only metadata for specific entities as needed instead of having to load the entire aggregate. Metadata is delivered through a protocol called MDQ ("Metadata Query," details at:

Why use per-entity metadata?

Instead of pre-loading and verifying all of the thousands of entity descriptors in the InCommon aggregate, your SP or IdP will only load entities on-demand. Your IdP, for example, may only regularly interact with a fraction of the total SPs in InCommon and will not have to load metadata for every single SP in to memory. This results in a significantly lower memory footprint in addition to quicker start up times by not having to verify the entirety of the aggregate at startup.  Using MDQ, the UK Federation reports that it is possible to run the Shibboleth IdP with as little as 500MB heap size compared to the current recommendation of a minimum heap size of 1.5GB.

Additionally, because metadata for a specific entity is available at a specific URL, it is possible to pre-fetch metadata for entities you may consider high-value, such as commonly-used entities. For example, an SP in InCommon that primarily interacts with a single IdP could pre-fetch and cache that one IdP on startup and refresh it on a regular basis (just as you would with the aggregate). This setup can help minimize risks specified below. 

System availability and performance

In a per-entity metadata service, an entity's metadata is fetched on-demand when federation software needs it. This typically occurs when a user attempts to access a service using his/her federated credential. This means that if the distribution service becomes unavailable and the metadata client has not cached the relevant metadata, a user would not be able to log in to the service he/she is trying to access.

Related: Amazon CloudFront's Service Level Agreement.

InCommon has engineered its metadata service to ensure high availability and performance by employing technologies such as deploying the service via a commercial CDN (Amazon CloudFront).  In addition, we are also developing automatic service monitoring to automatically sent alerts when there is anomaly. Stay tuned for updates on information about how to subscribe to these monitoring alerts.

Further reading