Page Comparison

...

For information on what goes into ensuring metadata is properly formatted, refer to the MetadataCorrectness topic.

...

Use (and non-use) of Metadata

...

An "entity" is just a server that's running SAML software to perform some task, such as an IdP or an SP. Each entity has a unique name, an entityID, that distinguishes it from any other. You are responsible for choosing an appropriate URL to use as an entityID, and both your configuration and the metadata you publish will contain that value. If they don't match, many problems will result.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://webauth.example.org/idp/shibboleth">
... example content not shown ...
</md:EntityDescriptor>

Roles

Once you get past the "entity" level, the main information unit is the "role". An entity is structured as a sequence of one or more "role descriptors", followed by optional contact/organization information for support purposes. The role elements make up the "meat" of the metadata you need to create/supply. In the case of Shibboleth, the most important roles tend to be <md:IDPSSODescriptor> and <md:AttributeAuthorityDescriptor> in the case of metadata about IdPs and <md:SPSSODescriptor> in the case of metadata about SPs.

For details and examples at this level of detail, please refer to the MetadataForIdP and MetadataForSP topics.

One extremely important piece of information common to all role elements is the protocolSupportEnumeration XML attribute, which MUST be present. This attribute contains a space-delimited collection of URIs that represent general classes of protocol support for the role in question. There are URIs defined by the various standards and profiles to represent the fact that an entity acting in a role "supports" a particular protocol family, such as SAML 2.0 or the Shibboleth profile of SAML 1.1.

...

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://webauth.example.org/idp/shibboleth">

  <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
  ... role content not shown ...
  </md:IDPSSODescriptor>

</md:EntityDescriptor>

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://service.example.org/shibboleth">

  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol">
  ... role content not shown ...
  </md:SPSSODescriptor>

</md:EntityDescriptor>

...

For testing purposes, you will rarely if ever need to supply these elements, but they may be needed for production use. Organization metadata in particular often gets used by other software systems that consume metadata in order to present lists of entities with human-readable names. Examples of such systems include IdPDiscovery services or software to assist users in granting consent for login and release of attributes to SPs.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://webauth.example.org/idp/shibboleth">

... role(s) not shown ...

  <md:Organization>
    <md:OrganizationName xml:lang="en">Example Organization, Ltd.</md:OrganizationName>
    <md:OrganizationDisplayName xml:lang="en">Example Organization</md:OrganizationDisplayName>
    <md:OrganizationURL xml:lang="en">http://www.example.org/</md:OrganizationURL>
  </md:Organization>

  <md:ContactPerson contactType="support">
    <md:GivenName>Authentication Support</md:GivenName>
    <md:EmailAddress>webauth-support@example.org</md:EmailAddress>
  </md:ContactPerson>
  <md:ContactPerson contactType="administrative">
    <md:GivenName>John</md:GivenName>
    <md:SurName>Doe</md:SurName>
    <md:EmailAddress>jdoe@example.org</md:EmailAddress>
  </md:ContactPerson>

</md:EntityDescriptor>

...

Broadly speaking the Shibboleth IdP and SP support roughly similar mechanisms for acquiring metadata, though the details vary. You can see the technical specifics in the IdPMetadataProvider and NativeSPMetadataProvider topics, but in general, there are three approaches one tends to see:

...