...

InCommon Discovery Service

The InCommon Discovery Service is a centralized IdP discovery interface for all InCommon participants. Visit our web site for a brief history of discovery or visit

Here is a projected timeline for deployment of the InCommon Discovery Service:

1. Wiki Markup
   \[Wed, Nov 17, 2010\] Pre-production Discovery Service released

2. Wiki Markup
   \[Wed, Dec 15, 2010\] New hot spare deployed in Indiana

3. Wiki Markup
   \[Wed, Jan 5, 2011\] Production Discovery Service to be released

4. Wiki Markup
   \[Wed, Feb 2, 2011\] Redirect from WAYF to Discovery Service

5. Wiki Markup
   \[Wed, Jul 6, 2011\] Redirect is permanently removed

Once a redirect from the WAYF to the Discovery Service is activated (on Feb 2), support for the InCommon WAYF will be discontinued. See the sections below for details how to configure your SP to use the InCommon Discovery Service instead of the InCommon WAYF.

Try out the new InCommon Discovery Service: https://service1.internet2.edu/test

Visit the Discovery Service FAQ for more information about the InCommon Discovery Service.

Software and Metadata Considerations

Configuring Metadata for Discovery

If your SP supports SAML V2.0, and the SP is configured to use the SAML V2.0 Identity Provider Discovery Protocol, you must configure your SP's metadata to include one or more <idpdisc:DiscoveryResponse> elements. If you don't, a request to a properly configured discovery service endpoint (such as the InCommon Discovery Service) will fail.

If you inspect InCommon metadata, you will find extension endpoints such as the following in SP metadata:

<DiscoveryResponse
<idpdisc:DiscoveryResponse index="1" 
    xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" 
    Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" 
    Location="https://carmenwiki.osu.edu/Shibboleth.sso/Login" index="1"/>

The namespace and binding attributes attached to the <DiscoveryResponse> <idpdisc:DiscoveryResponse> element are defined in the SAML V2SAML V2.0 Identity Provider Discovery Protocol and Profile specification. The endpoint location is the return address for the SP, that is, where the Discovery Service returns to once the user's preferred IdP has been determined.

If your SP supports SAML V2.0, and the SP is configured to use the SAML V2.0 Identity Provider Discovery Protocol, you must configure your SP's metadata to include one or more <DiscoveryResponse> elements. If you don't, a request to a properly configured discovery service endpoint (such as the InCommon Discovery Service) will fail.

If your SP Likewise if your SP is configured to issue SAML V2.0 authentication requests, you must add one or more SAML V2.0 <AsssertionConsumerService> <md:AsssertionConsumerService> endpoints to your metadata. (The same is true of SAML V1.1, by the way.) Failure to do so will result in errors when such requests are issued to IdPs, since your metadata will lack sufficient support for the desired protocol.

The Discovery Service and the IdP have similar requirements with respect to metadata. Both components will redirect the browser user back to the SP, but only to a trusted endpoint at the SP. Those endpoints must be called out in SP metadata, otherwise the protocol is violated and the redirect will not occur.

Configuring your SAML Service Provider Software

In general, configuring your SP software for discovery depends on the protocol(s) it supports. If your SP supports SAML V1.1 only, you must configure your SP to use the legacy WAYF protocol, which is based on the proprietary Shibboleth 1.x AuthnRequest protocol. If your SP supports SAML V2.0 only, you must configure your SP to use the SAML V2.0 Identity Provider Discovery Protocol. In that case, you must configure SP metadata as described in the previous section.

...