The InCommon Discovery Service is now operational as a pre-production service!
Here is a projected timeline for deployment of the InCommon Discovery Service:
[Wed, Nov 17, 2010] Pre-production Discovery Service released
[Wed, Dec 15, 2010] New hot spare deployed in Indiana
[Wed, Jan 5, 2011] Production Discovery Service to be released
[Wed, Feb 2, 2011] InCommon WAYF to be taken out of service
Once a redirect from the WAYF to the Discovery Service is installed (on Feb 2), support for the InCommon WAYF will be discontinued. See the sections below for details how to configure a Shibboleth 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
Please visit the Discovery Service FAQ.
How do I configure a Shibboleth 1.x SP to use the InCommon Discovery Service instead of the InCommon WAYF?
Note: As of June 30, 2010, Shibboleth 1.x is no longer supported by the Shibboleth Project, so you should upgrade your software as soon as possible.
A Shibboleth 1.x SP cannot take advantage of all the features of the new InCommon Discovery Service, so we recommend you upgrade your Shibboleth SP deployment as soon as you can. In the meantime, you can (and should) reconfigure your Shibboleth 1.x SP to use the InCommon Discovery Service instead of the InCommon WAYF. The latter will be phased out and retired early in 2011.
If you're already using the InCommon WAYF, you will find something like the following in your SP 1.x configuration file (shibboleth.xml):
<SessionInitiator id="wayf" Location="/WAYF/InCommon"
Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
wayfURL="https://wayf.incommonfederation.org/InCommon/WAYF"
wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" />
To point your SP at the new Discovery Service endpoint, make the following configuration change:
<SessionInitiator id="wayf" Location="/WAYF/InCommon"
Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
wayfURL="https://wayf.incommonfederation.org/DS/WAYF"
wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" />
Since the InCommon Discovery Service is backwards compatible with the InCommon WAYF, the above configuration should work exactly the same as before.
How do I configure a Shibboleth 2.x SP to use the InCommon Discovery Service instead of the InCommon WAYF?
In the very least, you should reconfigure your Shibboleth 2.x SP to use the InCommon Discovery Service instead of the InCommon WAYF. The latter will be phased out and retired early in 2011.
If you're already using the InCommon WAYF, you will find something like the following in your SP 2.x configuration file (shibboleth2.xml):
<SessionInitiator type="WAYF" URL="https://wayf.incommonfederation.org/InCommon/WAYF" />
To point your SP at the new Discovery Service endpoint, make the following configuration change:
<SessionInitiator type="WAYF" URL="https://wayf.incommonfederation.org/DS/WAYF" />
Since the InCommon Discovery Service is backwards compatible with the InCommon WAYF, the above configuration should work exactly the same as before.
How do I configure a Shibboleth 2.x SP to use the InCommon Discovery Service with the SAML V2.0 Identity Provider Discovery Protocol?
Important! The InCommon Discovery Service, and the use of SAML V2.0, depend on SP metadata, so update your metadata now, before you configure your Shibboleth 2.x SP to use the InCommon Discovery Service with the SAML V2.0 Identity Provider Discovery Protocol.
Assuming the specific <SessionInitiator> given below, the location of the return endpoint (i.e., the endpoint location at the SP that the DS returns to once the user's preferred IdP has been chosen) is:
https://host/Shibboleth.sso/Login
where host is the hostname of your SP. Simply login to the site admin web application, edit your SP's metadata, and add a <DiscoveryResponse> element with the above endpoint location.
You MUST also ensure that you have added SAML V2.0 endpoints and support to your metadata if your SP is configured to utilize SAML V2.0 (which it will be by default). Failure to do so will result in errors when SAML V2.0 requests are issued by the SP to Identity Providers in the federation that support SAML V2.0, because your metadata will indicate a lack of support for that protocol. Simply add an <AsssertionConsumerService> endpoint for the SAML V2.0 HTTP-POST Binding using the site admin web application.
Note: The InCommon Discovery Service is a pre-production test deployment, so we recommend you return your SP configuration to its original state after trying the sample configuration below. You can (and should) leave the <DiscoveryResponse> element and the SAML V2.0 changes in your metadata, however.
To use the InCommon Discovery Service with the SAML V2.0 Identity Provider Discovery Protocol, modify your SP 2.x configuration file (shibboleth2.xml) with something like this (the critical line is the second to last one containing "SAMLDS":
<SessionInitiator type="Chaining" Location="/Login" id="Login" isDefault="true" relayState="cookie">
<SessionInitiator type="SAML2"
defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html" />
<SessionInitiator type="Shib1" defaultACSIndex="5" />
<SessionInitiator type="SAMLDS" URL="https://wayf.incommonfederation.org/DS/WAYF" />
</SessionInitiator>
If this is the first time your SP has been configured for SAML V2.0, you should test the configuration thoroughly of course. In particular, you should test with your IdP partners to insure that both IdP and SP have been configured for SAML V2.0 correctly.
For More Information
- Shibboleth 2.x SP SessionInitiator https://spaces.at.internet2.edu/display/SHIB2/NativeSPSessionInitiator