Internet2

close
Use Internet2 SiteID

Already have an Internet2 SiteID?
Sign in here.

Internet2 SiteID

Your organization not listed? Create a local account to use Internet2 services.

Create SiteID

Blogs

Friends Don't Let Friends Use TLS for Metadata Consumption

Aug 28, 2017, by Nicholas Roy
Tags: InCommon Federation, Recent Posts, Trust & Identity

Those who are familiar with the InCommon Federation at a technical level will know what I mean when I write the following words:

Trust between federation partners in InCommon is rooted in the routine, automatic and secure consumption of federation metadata.

Occasionally, InCommon Operations receives requests to serve our metadata over TLS (HTTPS).  We intentionally do not do this. TLS provides transport security (an encrypted tunnel). However, the metadata, which contains all the public keys used for trust between Identity Providers and Service Providers, must be fully tamper proof both at rest and in transit. Customers must be able to verify that the metadata they received and are using is exactly the same metadata that was produced by the InCommon Federation Manager application and our global federation partners.

For these reasons, InCommon and other federations digitally sign our metadata documents using private keys that are heavily protected and secured by intentionally designed processes. Securely consuming metadata means carefully following InCommon documentation about downloading the public key for our metadata signing, and using that key to verify the digital signature on the metadata document at the time it is downloaded and used. Furthermore, because trustworthy and reliable interoperation among federation partners is based on the public keys and other configuration information within the metadata, it is critical that metadata consumers automatically download and then configure trust based on the metadata at least once per day.

Providing our metadata over TLS would give a false sense of security for customers running SAML software that does not correctly, securely and automatically consume metadata. Thus, it would encourage the deployment of non-interoperable SAML software in the federation, reducing the value proposition for other federation participants. If your software requires TLS for metadata consumption, please consider configuring one of the widely available HTTP servers or specialized proxies to handle this for you. If you do this, you are still responsible for consuming metadata daily and verifying the signature on metadata. Further, we strongly urge you to use software that fully conforms to the Kantara SAML v2.0 Implementation Profile for Federation Interoperability, a document authored largely by the InCommon Federation Interoperability Working Group with the intention of increasing the interoperability (and thus the utility) of federations.  You should feel free to use this document as a requirements guide for vendors of SAML software you intend to use with InCommon. If you want to run SAML software known to work by default, please consider running Shibboleth or SimpleSAMLphp. InCommon offers training on Shibboleth on a regular basis.