One of the key enabling technologies in Federation is Metadata. In the early days of SAML (yes there was a SAML 1.0) one of the more difficult aspects of setting up a federation relationship was exchanging signing certificates and unique identifiers. This often involved emailing public certificates and URNs back and forth, and in some cases, multiple times. In SAML 2 the problem got even worse because in addition to the sign on endpoints from SAML 1.0, there were now sign off endpoints to consider as well as more bindings.
The Age of Metadata
Fortunately, SAML 2 solved this problem using federation metadata. If you go to the metadata endpoint for a SAML 2 identity provider or relying party you can get an XML description that includes all the information needed to set up the federation relationship. For instance, the metadata for an identity provider would include the public cert matching the private key used to sign the response. It also typically includes the different SAML 2 endpoints as well as the claims available to the relying party. Setting up federations changed from being a time consuming, error prone activity to being as simple as clicking on a URL. Not only does Metadata make the initial setup of the Federation easier, but it allows the federated systems to remain up to date without human intervention when federation data changes. While the federation endpoints don’t typically change, the client certificates often expire and need to be updated periodically. Many federated systems support reading the metadata periodically, or at startup, and then updating the federation definitions if they are out of date.
Metadata Formats
Although the original WS-Federation standard did not define metadata, by convention many WS-Federation solutions also support publishing SAML 2 metadata. The OASIS version of WS-Federation does define a metadata format that is similar to the SAML 2 metadata. Most WS-Federation based solutions do not support the OASIS WS-Federation metadata standard and use the SAML 2 metadata format instead. OpenID Connect also defines a Metadata mechanism. As expected, it is JSON based rather than XML based. But like the SAML 2.0 Metadata, it defines the OAuth2 federation endpoints and PKI information. For Active Federation (SOAP based authentication) there are two additional Metadata formats involved. First, there is the WS-Metadata Exchange format Metadata (also known as MEX). Second, there is the venerable Web Services Description Language (WSDL) format Metadata. Active federation endpoints typically support both. One client application that depends on MEX metadata is the Skype for Business (formally known as Lync). Skype for Business Leverages the MEX Metadata to determine authentication endpoints as well as what kinds of authentication are supported (such as username/password, Windows authentication, etc.). In conclusion, there are at least four kinds of Metadata you are likely to run into in a federated environment; SAML 2 Metadata, OpenID Connect Metadata, MEX, and WSDL. Each of these Metadata formats play an important part in enabling the smooth set up and operation of federated systems.