IAM in Service Catalog
This document describes a method to configure a Shibboleth Service Provider (SP) to to fetch metadata only for specific IdPs as needed instead of periodically loading the entire InCommon "idp-only" aggregate. This new method is referred to as a per-entity metadata service or MDQ (since it is based on a "Metadata Query" protocol).
Traditionally, federated SPs that relied on InCommon Federation metadata would periodically download a large metadata aggregation file containing all InCommon entities (IdPs and SPs). This quickly grew unwieldy as the federation grew, and soon it was causing very slow start-up times and a large memory footprint for SPs. As an interim measure, InCommon began publishing an "IdP-only" metadata aggregate that was much smaller in size and that was less impactful on SPs. That approach also became unwieldy over time.
Now there is a new option called the InCommon Per-Entity Metadata Distribution Service. This service is analogous to DNS, but instead of looking up an IP address by hostname as needed and caching the result, it looks up InCommon metadata by entityID as needed and caches the result. The per-entity metadata service is also known as MDQ, after the IETF "Metadata Query" protocol that it uses. With MDQ, an SP only looks up IdP metadata when it needs to and it never loads metadata it doesn't need. There is no file to download and verify on restart and no large files to store on disk. If the MDQ service is not available, the SP will use a local copy of IdP metadata that it cached after previous successful MDQ queries.
For additional background please see: https://spaces.at.internet2.edu/display/MDQ/Introducing+per-entity+metadata+service
shibboleth2.xmlfile for editing.
Add the current
MetadataProvider with the following:
MetadataFilterelement requires that the signature on the
MDQ metadata providershould be verified using the
MetadataProviderfor the UW IdP or InCommon metadata aggregate, you should comment it out or delete it.
Configuring with multiple metadata providers
If you have more than one metadata provider configured (for example, for IdPs that are not part of InCommon), you will want to put the InCommon Per-Entity Metadata Distribution Service after any other metadata providers. Otherwise, your SP will needlessly attempt to use MDQ to fetch IdP metadata from InCommon before falling back to the correct metadata provider.
Shibboleth SP v2 is no longer supported
If you have not upgraded to Shibboleth SP v3 you should do so as soon as possible. Shibboleth SP v2 has already reached end of life and is no longer supported by the Shibboleth Consortium.
The per-entity metadata service works with Shibboleth v2 but there are some limitations:
Instructions for SP v2 configuration are the same as for SP v3, except the
MetadataProvider section is a little different:
shibboleth2.xmlfile. Name it
shibboleth2.xmland to take appropriate actions.
Look for messages like the following (numbering added for clarity, these are not present in the log file) to verify MDQ was configured on restart: