...
Frequently Asked Questions
| Table of Contents |
|---|
What is a "discovery service?"
...
To learn how a discovery service works, the SWITCH federation has an excellent series of demos that describe and illustrate how a discovery service integrates into a typical SAML flow.
What is the InCommon Discovery Service?
The InCommon Discovery Service is a deployment of the SWITCHwayf software implementation, a software project of the SWITCH federation.
IMPORTANT! The current InCommon Discovery Service is a pre-production test deployment of the SWITCHwayf software implementation.
The InCommon Discovery Service will eventually 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.
| HTML |
|---|
| HTML |
<ul>
<li>
<i>What is the InCommon Discovery Service?</i>
<div>
<br>
The <i>InCommon Discovery Service</i> is a deployment of the <i><a href=https://forge.switch.ch/redmine/projects/wayf id=n3cb title=SWITCHwayf>SWITCHwayf</a></i> software implementation, a <a href=http://www.switch.ch/aai/support/tools/wayf.html id=yaf: title="software project">software project</a> of the SWITCH federation.<br>
<br>
<b>IMPORTANT!</b> The current InCommon Discovery Service is a <b>pre-production test deployment</b> of the SWITCHwayf software implementation.<br>
<br>
The InCommon Discovery Service will eventually replace the InCommon WAYF (Where Are You From?) with a Federation-wide discovery service that supports the <i><a href=http://wiki.oasis-open.org/security/IdpDiscoSvcProtonProfile id=f8p9 title="SAML V2.0 Identity Provider Discovery Protocol and Profile">SAML V2.0 Identity Provider Discovery Protocol and Profile</a></i>. To ease the transition from the WAYF, the InCommon Discovery Service is backwards compatible with the InCommon WAYF.
</div>
</li>
</ul>
<ul>
<li>
<i>Why is InCommon replacing the WAYF with the Discovery Service?</i>
<div>
<br>
The current InCommon WAYF is not compatible with SAML V2.0. As Shibboleth 1.x is no longer supported by the Shibboleth Project, more organizations will be moving to Shibboleth 2.x and expecting to make use of SAML 2.0 features. In addition, the InCommon Discovery Service will leverage metadata, providing additional flexibility, privacy and security that the InCommon WAYF does not provide.
</div>
</li>
</ul>
<ul>
<li>
<i>Why is the InCommon Discovery Service a pre-production service at this time?</i>
<div>
<br>
The user interface of the pre-production InCommon Discovery Service is experimental. The production service will incorporate the feedback received from the community during the pre-production phase.<br>
</div>
</li>
</ul>
<ul>
<li>
<i>What does the InCommon Discovery Service look like?</i>
<br><br>Here's a recent screen shot of the InCommon Discovery Service:
</li>
</ul>
<div>
<img src="/download/attachments/17105174/screen_shot_DS">
</div>
<ul>
<li>
<i>Where can I try out the new InCommon Discovery Service?</i>
<div>
<br>
Please visit this test page: <a href=https://service1.internet2.edu/test/ id=o_xe title=https://service1.internet2.edu/test/>https://service1.internet2.edu/test/</a><br>
</div>
</li>
</ul>
<ul>
<li>
<i>Which SAML Service Provider implementations support the InCommon Discovery Service?</i>
<div>
<br>
The InCommon Discovery Service works with <b>all</b> supported versions of the Shibboleth Service Provider software. To use the native <i>SAML V2.0 Identity Provider Discovery Protocol</i>, Shibboleth SP version 2.0 (or later) is required.<br>
<br>
The InCommon Discovery Service is also believed to work with simpleSAMLphp version 1.1 or later, but this has not been tested by InCommon.<br>
<br>
There may be other SP implementations that support the InCommon Discovery Service. If you find one that does, please share your experiences with other InCommon participants (incommon-participants@incommon.org).<br>
</div>
</li>
</ul>
<ul>
<li>
<i>If my SAML Service Provider implementation supports an "embedded discovery service," do I still need to be concerned about the InCommon Discovery Service?</i>
<div>
<br>
The InCommon Discovery Service is a _centralized discovery service_ for general use within the InCommon Federation. For those service providers that provide their own discovery service, through an embedded service or some other centralized service, the InCommon Discovery Service may not be applicable. How you handle discovery in conjunction with particular federated services at your institution is completely up to you.<br>
<br>
That said, it is well known that an _embedded discovery service_ can provide the best overall experience for users, so you should by all means consider that as an alternative to centralized services such as the InCommon Discovery Service.<br>
</div>
</li>
</ul>
<ul>
<li>
<i>What do I need to do?</i>
<div>
<br>
First and foremost, try it out (<a href=https://service1.internet2.edu/test/ id=o_xe title=https://service1.internet2.edu/test/>https://service1.internet2.edu/test/</a>) and give us your feedback (discovery@incommon.org).<br>
<br>
<b>ALL</b> InCommon Service Provider deployments should reconfigure their software to point at the InCommon Discovery Service instead of the InCommon WAYF. The latter will be phased out and retired early in 2011.<br>
<br>
Update your InCommon Federation metadata to include the <font face="courier new"><DiscoveryResponse></font> extension endpoints that are required to use the service with SAML V2.0 Web Browser SSO. Do this even if you don't plan on using SAML V2.0 any time soon.<br>
<br>
Consult the Shibboleth documentation for instructions how to configure a Shibboleth 2.x SP <a href=https://spaces.at.internet2.edu/display/SHIB2/NativeSPSessionInitiator id=c0k2 title=SessionInitiator>SessionInitiator</a> with one or more discovery handlers. Instructions how to <a href="#config">configure your Shibboleth 2.x SP</a> to use the InCommon Discovery Service will be found elsewhere in this FAQ.<br>
</div>
</li>
</ul>
<ul>
<li>
<i>How do I configure a Shibboleth 1.x SP to use the InCommon Discovery Service instead of the InCommon WAYF?</i>
<div>
<br>
<b>Note:</b> 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.<br>
<br>
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.<br>
<br>
If you're already using the InCommon WAYF, you will find code like the following in your <a href=https://spaces.at.internet2.edu/display/SHIB/SessionInitiator id=r20z title="SP 1.x configuration">SP 1.x configuration</a> file (shibboleth.xml):<br>
<br>
</div>
<div>
<font face="courier new"><SessionInitiator id="wayf" Location="/WAYF/InCommon"</font><br style="FONT-FAMILY:Courier New">
<font face="courier new"> Binding="urn:mace:shibboleth:sp:1.3:SessionInit"</font><br style="FONT-FAMILY:Courier New">
<font face="courier new"> wayfURL="https://wayf.incommonfederation.org/InCommon/WAYF"</font><br style="FONT-FAMILY:Courier New">
<font face="courier new"> wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" /></font><br style="FONT-FAMILY:Courier New">
</div>
<div>
<br>
To point your SP at the new Discovery Service endpoint, make the following configuration change:<br>
<br>
</div>
<div style="FONT-FAMILY:Courier New">
<SessionInitiator id="wayf" Location="/WAYF/InCommon"<br>
Binding="urn:mace:shibboleth:sp:1.3:SessionInit"<br>
wayfURL="<b>https://wayf.incommonfederation.org/DS/WAYF</b>"<br>
wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" /><br>
</div>
<div>
<br>
Since the InCommon Discovery Service is backwards compatible with the InCommon WAYF, the above configuration should work exactly the same as before.<br>
</div>
</li>
</ul>
<ul>
<li>
<i>How do I configure a Shibboleth 2.x SP to use the InCommon Discovery Service instead of the InCommon WAYF?</i>
<div>
<br>
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.<br>
<br>
If you're already using the InCommon WAYF, you will find code like the following in your <a href=https://spaces.at.internet2.edu/display/SHIB2/NativeSPShibbolethXML id=f_-. title="SP 2.x configuration">SP 2.x configuration</a> file (shibboleth2.xml):<br>
<br>
</div>
<div style="FONT-FAMILY:Courier New">
<SessionInitiator type="WAYF" URL="https://wayf.incommonfederation.org/InCommon/WAYF" /><br>
</div>
<div>
<br>
To point your SP at the new Discovery Service endpoint, make the following configuration change:<br>
<br>
</div>
<div style="FONT-FAMILY:Courier New">
<SessionInitiator type="WAYF" URL="<b>https://wayf.incommonfederation.org/DS/WAYF</b>" /><br>
</div>
<div>
<br>
Since the InCommon Discovery Service is backwards compatible with the InCommon WAYF, the above configuration should work exactly the same as before.<br>
</div>
</li>
</ul>
<ul>
<li>
<a name="config"><i>How do I configure a Shibboleth 2.x SP to use the InCommon Discovery Service with the SAML V2.0 Identity Provider Discovery Protocol?</i></a>
<div>
<br>
<b>Important!</b> The InCommon Discovery Service depends on SP metadata, so <b>update your metadata now</b>, before you configure your Shibboleth 2.x SP to use the InCommon Discovery Service with the <i>SAML V2.0 Identity Provider Discovery Protocol</i>.<br>
<br>
Assuming the <font face="courier new"><SessionInitiator></font> 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:<br>
<br>
<font face="courier new">https://</font><i style="FONT-FAMILY:Courier New">host</i><font face="courier new">/Shibboleth.sso/Login</font><br>
<br>
where <i style="FONT-FAMILY:Courier New">host</i> is the hostname of your SP. Simply login to the site admin web application, edit your SP's metadata, and add a <font face="courier new"><DiscoveryResponse></font> element with the above endpoint location.<br>
<br>
<b>Note:</b> 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 <font face="courier new"><DiscoveryResponse></font> element in metadata, however.<br>
<br>
To use the InCommon Discovery Service with the <i>SAML V2.0 Identity Provider Discovery Protocol</i>, modify your <a href=https://spaces.at.internet2.edu/display/SHIB2/NativeSPShibbolethXML id=kwkk title="SP 2.x configuration">SP 2.x configuration</a> file (shibboleth2.xml) something like the following:<br>
<br>
</div>
<div style="FONT-FAMILY:Courier New">
<SessionInitiator type="Chaining" Location="/Login" id="Login" isDefault="true" relayState="cookie"><br>
</div>
<div style="FONT-FAMILY:Courier New">
<div>
<SessionInitiator type="SAML2"<br>
defaultACSIndex="1" <b>acsByIndex="false"</b> template="bindingTemplate.html" /><br>
<SessionInitiator type="Shib1" defaultACSIndex="5" /><br>
<SessionInitiator type="<b>SAMLDS</b>" URL="<b>https://wayf.incommonfederation.org/DS/WAYF</b>" /><br>
</div>
</SessionInitiator><br>
</div>
<div>
<br>
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.<br>
</div>
</li>
</ul>
|
...