...
The best by far is to utilize a known SessionInitiator at the SP protecting the desired resource and supply it the encoded EntityID for that IdP. For example, TestShib has a SessionInitiator located at https://sp.testshib.org/Shibboleth.sso/TestShib. If supplied an appropriately encoded entityID parameter of https://idp.testshib.org/idp/shibboleth, the SP will examine metadata to determine that it recognizes the IdP, and then select the right endpoints at the IdP and SP automatically. It will dispatch the AuthnRequest directly to the IdP, and the user, upon authentication, will arrive at the resource immediately. The complete request will then look like:
| Code Block |
|---|
https://sp.testshib.org/Shibboleth.sso/TestShib?entityID=https%3A%2F%2Fidp.testshib.org%2Fidp%2Fshibboleth
|
...
If the application knows the set of IdP's that might access it and the set is exceedingly small, then a simple approach to discovery on a flat page might work. For example, TestShib's registration application supports login only through OpenIdP and ProtectNetwork. The simplest and successful approach was to imbed logos for each of the providers on the page in the application itself, with the links going to a SessionInitiator for each provider. These links are very similar to the links described above, but they use a special SessionInitiator for each IdP, and they specify a target resource for the user to land at after authentication.
| Code Block |
|---|
<a href="https://www.testshib.org/Shibboleth.sso/ProtectNetwork?target=https%3A%2F%2Fwww.testshib.org%2Ftestshib-two%2Fauth-pages%2Fauth.jsp">
<img src="images/PN_sign-in.gif" alt="Login with ProtectNetwork" border="0">
</a>
<a href="https://www.testshib.org/Shibboleth.sso/OpenIdP.org?target=https%3A%2F%2Fwww.testshib.org%2Ftestshib-two%2Fauth-pages%2Fauth.jsp">
<img src="images/openidp.png" alt="Login with OpenIdP.org" border="0">
</a>
|
| Code Block | ||||
|---|---|---|---|---|
| ||||
<center>
<table cellpadding="5" border="1"><tr><td width="200" height="250"><table><tr><td width="200" height="125"><h3 style="text-align: center; margin-top: 20px">
<h3 style="text-align: center; margin-top: 20px">
<a href="https://www.testshib.org/Shibboleth.sso/ProtectNetwork?target=https%3A%2F%2Fwww.testshib.org%2Ftestshib-two%2Fauth-pages%2Fauth.jsp">
<img src="http://www.testshib.org/testshib-two/images/PN_sign-in.gif" alt="Login with ProtectNetwork" border="0"></a></h3></td></tr><tr><td height="125">
<h3 style="text-align: center; margin-top: 20px"><a href="https://idp.protectnetwork.org/protectnetwork-idp/registration.html" target="_new">
<img src="http://www.testshib.org/testshib-two/images/PN_register.gif" alt="Register a new ProtectNetwork identity" border="0"></a><br/><br/>
</h3></td></tr></table>
</td><td width="175" height="250"><h3 style="text-align: center; margin-top: 20px">
<a href="https://www.testshib.org/Shibboleth.sso/OpenIdP.org?target=https%3A%2F%2Fwww.testshib.org%2Ftestshib-two%2Fauth-pages%2Fauth.jsp">
<img src="http://www.testshib.org/testshib-two/images/openidp.png" alt="Login with OpenIdP.org" border="0"></td></tr>
</table>
</center>
|
...
The user is generally sent directly to the DS in a redirect, but more modern DS implementations (e.g. SWITCH'S WAYF or the s WAYF, the Embedded Discovery Service or DiscoJuice) also also allow an application to directly embed a discovery interface into a page. The interface can be customized by that page. The following is an example from the SWITCH implementation.
...
The DS can be operated by the resource, or it can be run as a central, shared service. There are advantages and drawbacks to either approach.
Run with the Resource
If the resource operates its own DS, it can present the smallest list of potential choices to the user. The resource knows the full set of IdP's it will accept, and it knows which federations it has partnerships with. This is particularly valuable for services serving a large number of communities, or a small subset of a large community.
...