...
Static HTML leveraging the SP's SessionInitiator support is often sufficient for discovery when there is a limited and static set of IdP's to choose from, and is simple and clean to implement.
...
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:
...
This can be placed in any link on any page. The user will authenticate if they haven't already, and they will end up at the application. A separate target can also be added to specify the page at which the user should land.
If the SessionInitiator is not known, then it's possible to forge an AuthnRequest on behalf of the SP based only on information that is present in metadata. This was a common approach with the query string-based authentication requests in Shibboleth 1.x, but it's considerably more difficult with the XML-based, encoded requests in SAML 2.0. It's listed here as an option, but strongly recommended against.
...
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 | ||||
|---|---|---|---|---|
| ||||
<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>
|
Discovery Service
A Discovery Service (DS) is a service that presents a standard interface for users to select their IdP from. A DS presents in some form, highly customizable, a set of IdP's from which the user can choose. After the user makes a selection, the DS redirects the user to the SP, which then formulates the AuthnRequest based on the user's selection.
...
As a drawback, this requires the SP to maintain its own DS, and can lead to an inconsistent experience for users. Please consult the DiscoveryService documentation to understand how to set up and operate a DS.
...