Frequently Asked Questions
| HTML |
|---|
Where<ul> can I try out the new InCommon Discovery Service? Just visit this test page:https://service1.internet2.edu/test/ What <li> <i>What is a "discovery service?"</i> <div> <br> Generally speaking, adiscovery serviceis a solution to theidentity provider discoveryproblem<i>discovery service</i> is a solution to the <a href=https://spaces.at.internet2.edu/display/SHIB2/IdPDiscovery id=xpcs title="identity provider discovery">identity provider discovery</a> problem, a longstanding issue in the federated identity management space. As the term is used here, adiscovery serviceprovides a <i>discovery service</i> provides a browser-based interface where a user selects his or her home organization (i.e., identity provider). A service provider uses this information to initiate SAML Web Browser SSO.<br> <br> The phrase "Where Are You From?" (WAYF) is often used to characterize IdP discovery. Historically, the term "WAYF" has referred to both software and protocol. The WAYF software has all but been eliminated by newer discovery service implementations (such as this one), but the WAYF protocol lives on, mainly for backwards compatibility with SAML V1.1.<br> <br> In addition to the WAYF protocol, a discovery service implements theSAMLthe <i><a href=http://wiki.oasis-open.org/security/IdpDiscoSvcProtonProfile id=zw84 title="SAML V2.0 Identity Provider Discovery Protocol">SAML V2.0 Identity Provider Discovery Protocol</a></i>. This protocol differs from the WAYF protocol in one very important respect. Whereas the WAYF protocol forwards an authentication request directly to the identity provider, theIdentitythe <i>Identity Provider Discovery ProtocolreturnsProtocol</i> returns control to the service provider, which provides increased flexibility, privacy and security.<br> <br> To learn how a discovery service works, the SWITCH federation has anexcellent an <a href=http://www.switch.ch/aai/demo/ id=a_-o title="excellent series of demos">excellent series of demos</a> demosthatthat illustrate how a discovery service integrates into a typical SAML flow. </div> </li> </ul> <ul> What <li> <i>What is the InCommon Discovery Service?</i> <div> TheInCommon Discovery Serviceis <br> The <i>InCommon Discovery Service</i> is a deployment of theSWITCHwayfsoftware implementation, asoftware projectof the SWITCH federation. IMPORTANT!The InCommon Discovery Service is apre-production test deploymentof 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 theSAML V2.0 Identity Provider Discovery Protocol and Profile. To ease the transition from the WAYF, 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 InCommon Discovery Service is a <b>pre-production test deployment</b> of the SWITCHwayf software implementation.<br> <br> The InCommon Discovery Service iswill backwardseventually compatible withreplace the InCommon WAYF. Why is InCommon replacing the WAYF with the Discovery Service? The current InCommon WAYF is not compatible with (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 orIdentity Shibboleth 2.x. As Shibboleth 1.x is no longer supported by the Shibboleth Project, more organizations will be moving to Shibboleth 2.x. In addition, the production version of the InCommon Discovery Service will leverage metadata, providing additional flexibility, privacy and security that the InCommon WAYF does not provide. Why is the InCommon Discovery Service a pre-production service at this time? 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. The pre-productionProvider 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 or Shibboleth 2.x. As Shibboleth 1.x is no longer supported by the Shibboleth Project, more organizations will be moving to Shibboleth 2.x. In addition, the production version of the InCommon Discovery Service doeswill notleverage currentlymetadata, takeproviding advantageadditional offlexibility, Federationprivacy metadata.and Thesecurity productionthat servicethe willInCommon leverageWAYF Federationdoes metadata to increase the flexibility, privacy and security of the deployment. There is no standbynot provide. </div> </li> </ul> <ul> <li> <i>Why is the InCommon Discovery Service toa failpre-production overservice inat case of an outage.this time?</i> <div> What does the <br> The user interface of the pre-production InCommon Discovery Service look like? Here's a recent screen shot ofis experimental. The production service will incorporate the InCommonfeedback Discovery Service: Which SAML Service Provider implementations support the InCommon Discovery Service? Thereceived from the community during the pre-production phase.<br> <br> The pre-production InCommon Discovery Service does not workscurrently withallsupportedtake versionsadvantage of theFederation Shibbolethmetadata. ServiceThe Provider software. To use the nativeSAML V2.0 Identity Provider Discovery Protocol, Shibboleth SP version 2.0 (or later) is required. Theproduction service will leverage Federation metadata to increase the flexibility, privacy and security of the deployment.<br> <br> There is no standby InCommon Discovery Service alsoto worksfail withover simpleSAMLphpin versioncase 1.1of or later, but this has not been tested. There may be other SP implementations that supportan outage.<br> </div> </li> </ul> <ul> <li> <i>What does the InCommon Discovery Service. If you find one that does, please share your experiences with us (discovery@incommon.org). If my SAML Service Provider implementation supports an "embedded discovery service," do I still need to be concerned about look like?</i> <br><br>Here's a recent screen shot of the InCommon Discovery Service: </li> </ul> <div> <img src="/download/attachments/17105174/dm8mb2j_1f7bntqcq_b.jpg"> </div> <ul> <li> <i>Which SAML Service Provider implementations support the InCommon Discovery Service?</i> <div> <br> The InCommon Discovery Service isworks awith centralized<b>all</b> discoverysupported serviceversions forof generalthe useShibboleth withinService theProvider InCommon Federationsoftware. ForTo thoseuse servicethe providersnative that<i>SAML provideV2.0 theirIdentity ownProvider discoveryDiscovery serviceProtocol</i>, throughShibboleth anSP embeddedversion service2.0 (or some other centralized service, the later) is required.<br> <br> The InCommon Discovery Service mayalso notworks bewith applicable.simpleSAMLphp Howversion you1.1 handleor discoverylater, inbut conjunctionthis withhas particularnot federated services at your institution is completely up to you. That said, it is well known that embedded discovery provides 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. What do I need to do? First and foremost, try it out and give us your feedback (discovery@incommon.org). AllService 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 eventually retired. Consult the Shibboleth documentation for instructions how to configure a Shibboleth 2.x SPSessionInitiatorwith one or more discovery handlers. Once you've configured (and tested) your Shibboleth 2.x SP to use the InCommon Discovery Service, update your InCommon Federation metadata to include theendpoints that will be required to access the production service. Where can I try out the new InCommon Discovery Service? Just visit this test page:https://service1.internet2.edu/test/ 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 1been tested.<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 us (discovery@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 embedded discovery provides 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 and give us your feedback (discovery@incommon.org).<br> <br> <b>All</b> 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 eventually retired.<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. Once you've configured (and tested) your Shibboleth 2.x SP to use the InCommon Discovery Service, instead ofupdate your InCommon Federation metadata to include the InCommon WAYF. The latter <font face="courier new"><DiscoveryResponse></font> endpoints that will be required phasedto outaccess andthe eventuallyproduction retiredservice.<br> </div> If you're already using the InCommon WAYF, you will find something like this in yourSP 1.x configurationfile (shibboleth.xml): 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: Binding="urn:mace:shibboleth:sp:1.3:SessionInit" wayfURL="https://wayf.incommonfederation.org/DS" 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 </li> </ul> <ul> <li> <i>Where can I try out the new InCommon Discovery Service?</i> <div> <br> Just 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>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 eventually retired.<br> <br> If you're already using the InCommon WAYF, you will find something like this in yourSPyour 2.x configurationfile (shibboleth2<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> To point your SP at the new Discovery Service endpoint, make the following configuration change: Since the</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</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 eventually retired.<br> <br> If you're already using the InCommon WAYF, you will find something like this 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</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> <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> <div> <br> <b>Note:</b> 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? 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. To use the InCommon Discovery Service with theSAML V2.0 Identity Provider Discovery Protocol, modify yourSP 2.x configurationfile (shibboleth2.xml) something like the following: defaultACSIndex="1"acsByIndex="false"template="bindingTemplate.html" /> a pre-production test deployment, so we recommend you return your SP configuration to its original state after trying the sample configuration below.<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="/DS" id="DS" 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</b>" /><br> </div> </SessionInitiator><br> </div> <div> <br> Normally, the above configuration change would be followed by a change to SP metadata, but since the pre-production test version of the InCommon Discovery Service does not use metadata, that step can be skipped for now. We recommend, however, that you youupdate<b>update your Federation metadata nownow</b>, as suggested in the following FAQ. Then, when the production version of the InCommon Discovery Service is released, you'll be ready to go. <br> </div> </li> </ul> <ul> How <li> <i>How do I update Federation metadata to leverage the InCommon Discovery Service?</i> <div> Note: <br> <b>Note:</b> The pre-production test deployment of the InCommon Discovery Service does not require SP metadata, but the production service will, so now is a good time to update your metadata. Using thein your metadata.<br> <br> Using the <font face="courier new"><SessionInitiator></font> in the previous FAQ, the location of the return endpoint (i.e., the endpoint location at the SP that the DS returns the user to, once the user's preferred IdP has been chosen) is: https://host 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/DS</DSfont><br> wherehostis <br> where <i style="FONT-FAMILY:Courier New">host</i> is the hostname of your SP. Now simply login to the site admin web application, edit your SP's metadata, and add aelement and add a <font face="courier new"><DiscoveryResponse></font> element with the above endpoint location.<br> <br> For now, that's all that can be done. When the production version of the InCommon Discovery Service is finally released, you can modify theas the <font face="courier new"><SessionInitiator></font> as in the previous FAQ and test by requesting a protected resource at the SP.<br> </div> </li> </ul> |
If you have any problems, drop us a line at discovery@incommon.org.
...