SAML metadata
Over time, as the number of SAML partners grows, the natural tendency is to automate the metadata sharing process.
To fully automate the metadata sharing process, a standard file format is needed.
Every metadata file that is statically configured into the SAML application by an administrator incurs technical debt.
One approach is to enlist the help of a trusted third party whose responsibility it is to collect, curate, and distribute metadata across the network.
The contribution included a document entitled Liberty Metadata Description and Discovery Specification Version 1.0,[LibertyMeta 1] which included the following design goals: As it turns out, all of those goals were preserved in the OASIS SAML V2.0 Metadata Standard described later in this article.
(Peter Davis, Personal Communication) Between November 2003 (when Version 1.0 was contributed to OASIS) and December 2004 (when Version 1.1 was completed by Liberty), development of the Liberty metadata specification continued in parallel with the OASIS work stream.
Between March and July 2004, the fledgling SAML Metadata specification underwent significant churn.
In July 2004, the SSTC issued a public call for comments covering a complete set of SAML V2.0 draft specifications.
After the final Committee Draft was published in November 2004,[SAMLMeta 3] the SSTC began the standardization process in January 2005.
[OS 1] A decade later, in September 2015, OASIS published a revised SAML Metadata specification with errata.
A select subset of these Committee Specifications are listed in the References section at the end of this article.
As it turns out, the influence of the Liberty Identity Federation Framework on SAML Metadata predates the contribution of ID-FF 1.2 in November 2003.
Since the Liberty Alliance Web SSO Profiles are directly based on the SAML Web SSO Profiles, the metadata defined in this document borrows extensively from the metadata definitions in the draft Liberty Alliance 1.2 specifications.
Indeed, the revision history at the end of the previous draft[SAMLMeta 5] shows a trail of metadata specifications dating back to November 2002.
Following the document trail, the influence of Liberty ID-FF on SAML metadata can be traced to a draft specification published in April 2003.
With that, we offer the following summary and conjecture: As mentioned earlier, the SAML V2.0 Metadata Schema[OS 4] has numerous extension points.
The more popular metadata extensions are listed below for convenience (see the examples for specific use cases): An important "Post-V2.0" specification is the SAML V2.0 Metadata Interoperability Profile,[CS 7] which builds on the premise that a formal public key infrastructure (PKI) can be extremely complex and in some cases intractable (it is well known, for example, that browser-facing TLS certificate revocation is broken[Misc 1]).
In essence, the Metadata Interoperability Profile is an attempt to provide a workable key revocation mechanism for SAML federations.
Since its publication in August 2009, the Metadata Interoperability Profile has been a particularly influential document, especially in higher education (see, for example, the certificate-related requirements for deployers[Misc 2] in one large R&E federation).
[Misc 3]Indeed, the key feature that distinguishes a scalable SAML implementation (from one that is not) is metadata interoperability.
The following code sample illustrates the common technical features of a SAML
The SAML metadata specification defines numerous concrete instances of the md:RoleDescriptor abstract type (section 2.4.1 of SAMLMeta[OS 3]).
The following example illustrates two such endpoints: The content of the
Trusted endpoint locations in metadata How does the Discovery Service know where to send the user with the IdP entityID?
Trusted endpoint locations in metadata How does the service provider know where to send the user with the SAML Request?
In this case, the identity provider includes a SAML2 Transient NameID (SAMLCore[OS 6]) in the SAML Assertion.
The identity provider includes two user attributes in the SAML Assertion: eduPersonUniqueId and mail.
A metadata-aware IdP will consult the
At run time, the identity provider observes that the WantAssertionsSigned XML attribute in metadata is set to true.
The original SAML V2.0 standards published in March 2005 have been deprecated in favor of the revised specifications with errata listed further below.
