Jump to: 

The InCommon Discovery Service lets a user look up his/her home organization when accessing a resource in the InCommon Federation. The resource provider uses information provided by the discovery service to direct the user to the correct identity provider to sign-in.

Configure service provider to use the InCommon Discovery Service

Configuring your service provider (SP) software for discovery depends on the protocol(s) it supports:

If your SP only supports SAML V1.1

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

Configure your SP to use the SAML V2.0 Identity Provider Discovery Protocol. Follow configure SP metadata as described in the previous section. Do this even if your SP supports SAML V1.1 as well. This configuration offers a much richer set of deployment options.

If you are configuring a Shibboleth SP software for discovery, please see the Configure Shibboleth SP for discovery topic for additional considerations.


Some SP implementations are sophisticated enough to make a runtime decision based on the supported protocols called out in IdP metadata.

Configure metadata for SAML V2.0 Identity Provider Protocol

If your service provider(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:

<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"/>

The namespace and binding attributes attached to the <idpdisc:DiscoveryResponse> element are defined in the SAML 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 is configured to issue SAML V2.0 authentication requests, you must add one or more SAML V2.0 <md:AsssertionConsumerService> endpoints to your metadata. (The same is true of SAML V1.1.) 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.

Additional Information

The InCommon Discovery Service is a deployment of the SWITCHwayf software implementation, a software project of the SWITCH federation. The InCommon Discovery Service will replace the InCommon WAYF (Where Are You From?) with a Federation-wide discovery service that supports the SAML V2.0 Identity Provider Discovery Protocol and Profile. To ease the transition from the WAYF, the InCommon Discovery Service is backwards compatible with the InCommon WAYF.

Visit our web site for a brief history of discovery or visit the 2024-04-05_19-15-41_Discovery Service FAQ for more information about the InCommon Discovery Service.


In this section

Related content


Get help

Can't find what you are looking for?