InCommon Service Provider Deployment Guide

Recommended server configurations for Service Providers (SPs):

Each distinct service provider being deployed must be assigned a unique identifier, called a "provider ID." This is analogous to the identifiers issued to identity providers and is in the form of a URI. Since we expect service providers will need to interact with a variety of identity providers from different federations (such as those outside of the US), we encourage deployers to self-select a provider ID URL from their own domain. In the future, this URL could be used to directly obtain metadata about a service, so the choice of URL might reflect this.

As an example, consider a DSpace repository running at Ohio State that will make content available to other sites. A possible provider ID for this service might be "https://dspace.osu.edu/shibboleth". A XML document containing metadata for the service might be placed behind this URL, in addition to being distributed by a federation, to simplify out of band arrangements.

Shibboleth 1.3 and later versions of Shibboleth support metadata in the format defined by the SAML 2.0 specification and related profile and extension documents that define how this format can be used with SAML 1.x components. The relevant specifications can be found in:

An example document for a newer service provider might consist of the following:


<EntityDescriptor entityID="https://dspace.osu.edu/shibboleth"
    xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    validUntil="2010-01-01T00:00:00Z">
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
        <KeyDescriptor>
            <ds:KeyInfo>
                <ds:KeyName>dspace.osu.edu</ds:KeyName>
                <ds:X509Data>
                    <ds:X509Certificate>
[base64-encoded certificate used by SP]
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>
        <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
        <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
            Location="https://dspace.osu.edu/Shibboleth.sso/SAML/POST"/>
        <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
            Location="https://dspace.osu.edu/Shibboleth.sso/SAML/Artifact"/>
    </SPSSODescriptor>
    <Organization>
        <OrganizationName xml:lang="en">OSU DSpace Service</OrganizationName>
        <OrganizationDisplayName xml:lang="en">OSU DSpace Service</OrganizationDisplayName>
        <OrganizationURL xml:lang="en">http://dspace.osu.edu/</OrganizationURL>
    </Organization>
    <ContactPerson contactType="technical">
        <SurName>OSU DSpace Support</SurName>
        <EmailAddress>dspace@osu.edu</EmailAddress>
    </ContactPerson>
</EntityDescriptor>

A service provider running 1.2 or earlier would not have the second AssertionConsumerService element for the Browser/Artifact profile; and, the POST profile Location would probably resemble "https://dspace.osu.edu/Shibboleth.shire".
For compatibility with the 1.2 release, service providers must also supply metadata using a much simpler, but proprietary, syntax. Example metadata might consist of: 

<DestinationSite Name="https://dspace.osu.edu/shibboleth">
    <Contact Type="technical" Name="OSU DSpace Support" Email="dspace@osu.edu"/> 
    <AssertionConsumerServiceURL Location="https://dspace.osu.edu/Shibboleth.sso/SAML/POST"/>
    <AttributeRequester Name="dspace.osu.edu"/>
</DestinationSite>

In both formats, the information that must be supplied consists of the following:

In older software releases, the latter piece of information was exchanged out of band in order for identity providers to establish attribute release policies (ARPs) by recognizing the name in the certificate. With newer releases, this is still supplied, but is now in metadata. ARPs are created using only the service's provider ID, allowing the certificate to change in the future without impacting ARPs.

The new information being supplied in metadata is about the SP's assertion consumer service endpoints, (in older releases, the "shire" location). This is checked at runtime by identity providers to insure that user information is only sent to authorized locations.

For more information or questions about the technical requirements for InCommon please send mail to: incommon-admin@incommonfederation.org