The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



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

Compare with Current View Page History

« Previous Version 50 Next »

The InCommon Discovery Service is now operational as a pre-production service!

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

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

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

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

  4. [Wed, Feb 2, 2011] InCommon WAYF to be taken out of service

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
Send comments, feedback and questions to: discovery@incommon.org

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

Software and Metadata Considerations

Configuring Metadata for Discovery

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

<DiscoveryResponse> metadata extension element
<DiscoveryResponse 
  xmlns="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> 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 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 is configured to issue SAML V2.0 authentication requests, you must add one or more SAML V2.0 <AsssertionConsumerService> endpoints to your metadata. Failure to do so will result in errors when such requests are issued to IdPs that support SAML V2.0 since your metadata will indicate a lack of support for that protocol.

Configuring your SAML Service Provider Software

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.

Of course, if your SP supports both SAML V1.1 and SAML V2.0, you have a choice, but clearly SAML V2.0 is preferred since it offers a much richer set of deployment options. Some SP implementations are sophisticated enough to make a runtime decison for you, based on the supported protocols called out in IdP metadata.

Instructions how to configure the Shibboleth SP for discovery can be found elsewhere in this wiki.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels