Use Internet2 SiteID

Already have an Internet2 SiteID?
Sign in here.

Internet2 SiteID


Efficiency and Trust in InCommon's SAML Metadata

Apr 18, 2017, by Nicholas Roy
Tags: Frontpage News, InCommon

InCommon's staff, participant community, governance, and technical advisory groups work hard to ensure the trustworthy and efficient operation of InCommon services. We recently identified a long-standing business process which provides little value to the community, but was time consuming for both participants and staff.

Every participant includes certain elements in the metadata they upload for inclusion in the InCommon aggregate. One of these elements is endpoint locations -- URLs that are critical for security and interoperability. InCommon has required that these endpoints include domains that are owned by the organization submitting the metadata. We would accept an endpoint location from, for instance, if the endpoint location started with the prefix

With the increase in outsourced or cloud Identity Providers, this requirement has become a barrier. Services run on behalf of InCommon Participants by other organizations could not be approved for use in the federation without an onerous and sometimes impossible-to-complete process. Options used to meet this requirement included creation of DNS records at InCommon Participant organizations which then pointed to addresses at service providers, or, sometimes, a series of domain ownership proofs in the form of communication with DNS registrars.

There are some very specific parts of SAML metadata which must be rooted in DNS names controlled by organizations submitting metadata. But SAML endpoints confer no specific trust characteristics based on their DNS namespace and the checks on endpoint locations have been a time-consuming business process. Some InCommon Participants requested a change in InCommon’s SAML endpoint policy to allow them to deploy Service Provider software more easily.

InCommon staff members agreed that the endpoint policy could change with no affect on the overall trust model. InCommon Operations brought a proposed change to its advisory group and then to the InCommon Technical Advisory Committee (TAC). All agreed that removing the endpoint location requirement would not affect the trust fabric and would help both InCommon Operations and participants. As of Monday, April 10, 2017, InCommon stopped enforcing rules about endpoint locations.

While we believe this change should save time for submitters of Service Provider metadata in particular, all entity deployers, particularly Identity Provider deployers, should consider the implications of using endpoint locations that are not rooted in their own domains very carefully.  For example,

  • Use of single sign-on endpoints in cloud or other outsourced solutions could result in login pages outside of the organizational DNS namespace. This can result in users being trained to input their institutional credentials into a login screen outside of their organization. In turn, this could inadvertently train users to respond to phishing attempts in ways they should not.
  • Use of a vendor's domain for endpoints will make a future migration to another vendor more difficult.

Deployers are advised to think long and hard before deciding to use a domain they do not control for their endpoints. At the same time, InCommon Operations will continue to review existing practices, looking for ways to reduce barriers, both providing benefits to participants and maintaining the necessary trust in the metadata and in the InCommon Federation overall.