Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The Metadata topic covers the general structure of metadata for any entity. This topic will specifically cover the parts that describe an SP. This is an overview of how to create metadata about an SP, which you will give to an IdP. If you're looking for the reverse, that's here.

Shibboleth-Specific Tip

When first starting out, you can usually begin by relying on the SP software to generate an initial set of metadata about itself, once you've configured it, by accessing a URL like https://service.example.org/Shibboleth.sso/Metadata

This will only help if you've already configured the SP's entityID and credentials, and properly established the web server's virtual hostname information. Even then, it may not be exactly what you need, but it should be helpful to look at and edit from.

General Structure

SP metadata is contained within the <md:SPSSODescriptor> role element. As with all roles, you MUST include the proper protocolSupportEnumeration value to reflect the protocol families the SP supports, as descibed in the Metadata topic. Failure to do so will prevent the IdP from recognizing the SP properly.

An SP role typically includes the following descriptive information:

  • the public key(s) used by the SP for authentication and encryption
  • endpoints of various types for communicating with it
  • explicitly supported identifier formats, if any
  • descriptions of the "services" offered by the SP and the SAML attributes required by them

The order of all this information is significant, which you can refer to the schema for, but the most common elements included would be present in the following order:

  • <md:KeyDescriptor> (can be omitted, but rarely)
  • <md:SingleLogoutService> (if any)
  • <md:NameIDFormat> (if any)
  • <md:AssertionConsumerService> (always at least one)
  • <md:AttributeConsumingService> (rare today, but good practice to include)

Keys

Refer to the MetadataKeyDescriptor topic for assistance with describing keys.

Shibboleth-Specific Tip

The keys you identify in the metadata MUST match the keys you configure into the SP as credentials. If they don't match, your SP may be unable to decrypt information from the IdP, or will be unable to negotiate SOAP connections to query for attributes.

Logout

If your SP supports SAML 2.0 Single Logout, you will need to include one or more <md:SingleLogoutService> endpoint elements in the metadata.

Shibboleth-Specific Tip

The Location attribute of Logout endpoints is derived from the logout handlers defined in the SP. As with all SP handlers, the locations will typically be of the form scheme + vhost + "/Shibboleth.sso" + Location, where Location is determined from the handler element in the configuration.

The elements must also include a Binding attribute, which can be copied directly from the handler element in the configuration.

Documenting Identifiers

An SP can identify specific "formats" of SAML name identifiers that it supports by listing each supported Format URI inside a <md:NameIDFormat> element. If it doesn't care (perhaps because it relies solely on SAML attributes), it can omit this element from its metadata.

Shibboleth-Specific Tip

This isn't used all that often for Shibboleth SPs, which tend to be more attribute-centric in the use of SAML, but the 2.x IdP software can utilize this information in its format selection process.

Assertion Consumer Services

SPs support SSO protocols by including one or more <md:AssertionConsumerService> endpoint elements in their metadata. These are the locations to which the IdP will eventually send the user at the SP. By enumerating them in the metadata, the IdP can ensure that the user's information is sent only to authorized locations.

Shibboleth-Specific Tip

The Location attribute of SSO endpoints is derived from the assertion consumer services defined in the SP. As with all SP handlers, the locations will typically be of the form scheme + vhost + "/Shibboleth.sso" + Location, where Location is determined from the handler element in the configuration.

The elements must also include a Binding attribute, which can be copied directly from the handler element in the configuration.

Documenting Attributes

Examples

  • No labels