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 Metadatametadata

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.

Tags

  • The database in which all of your organization’s sensitive identity data is stored.
  • A digital ledger in which digital transactions are recorded chronologically and publicly.
  • Securely managing customer identity and profile data, and controlling customer access to applications and services.
  • The means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.
  • A legal framework that sets guidelines for the collection and processing of personal information of individuals within the EU.
  • The policy-based centralized orchestration of user identity management and access control.
  • An authentication infrastructure that is built, hosted and managed by a third-party service provider.
  • A security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction.
  • A global provider of innovative and affordable identity access management solutions. 
  • Managing and auditing account and data access by privileged users.
  • Tools and technologies for controlling user access to critical information within an organization.
  • An authentication process that allows a user to access multiple applications with one set of login credentials.