This document describes the options for a Service Provider to obtain UW IdP metadata. Recommendations based on specific use cases are provided.

Background

The UW is part of InCommon and publishes its IdP metadata with the federation. Metadata can be consumed from InCommon in one of two ways:

• The traditional way InCommon published metadata was by hosting a digitally signed file of all IdP and SP metadata from its members.
  • As the federation grew, this file became large and unwieldy. It took so long to download it and verify the digital signature that some IdPs and SPs would run out of memory, be slow to start, or even hang.
  • At that point InCommon introduced the IdP-only metadata aggregate file. This file was much smaller and temporarily solved the memory and slowness issues previously experienced by many SPs.
  • However, rapid growth of the federation and the metadata file continued and it became clear a better solution was needed.
• To mitigate these issues, InCommon released their Per-Entity Metadata Distribution Service.
  • This service, also know as MDQ (based on the IETF “Metadata Query” protocol), allows an SP with MDQ support to query for a specified IdP’s metadata when it is needed and to cache the metadata locally.
  • This is analogous to the way DNS works. Current Shibboleth software has MDQ support.

In addition to publishing IdP metadata with InCommon, the UW publishes a signed metadata file at a local IdP endpoint. This can provide a good option for some use cases.

Options and Recommendations

The option to use for obtaining IdP metadata depends on what an SP needs to do (integrate only with the UW IdP or multiple InCommon IdPs) and what metadata capabilities it has (e.g. MDQ support). The table below outlines some use cases and makes recommendations for each. The links in the table provide instructions for each configuration option.