The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.

IdPDiscovery

IdPDiscovery is the process by which a ServiceProvider identifies the appropriate IdentityProvider to use for a given principal. In general, today, this is a difficult problem to solve because web browsers are unaware of the interactions that take place in single sign-on systems. Web sites use redirection and forms to trick browsers into carrying out complex sequences of steps that result in authentication, but the browser treats these interactions no differently than any other web pages.

If the browser could tell an SP what IdPs the user has a relationship with, the SP could choose an appropriate !IdP and initiate a request directly to it. Unfortunately, this is not possible yet except through additional web-based interactions that take advantage of cookies and other standard features to simulate this kind of intelligent dialog.

One means of handling discovery is the so-called WAYF, a web-based DiscoveryService component that acts as a proxy to relay an AuthnRequest from an SP to an !IdP once it has determined which one to use. Unfortunately, this doesn't scale very well beyond a single set of coooperating systems, or to put it another way, beyond a single federation. An additional problem is that in the future, it's going to be useful for SPs to digitally sign their AuthnRequests, as in SAMLTwodotZero. In complex environments, the SP's choice of signing key may depend on which !IdP to whom it wants to send the request. This is impossible in the WAYF model.

Another mechanism defined for discovery is a shared/common domain cookie maintained jointly across a set of sites, as defined in SAMLTwodotZero. Unfortunately, this mechanism scales even more poorly when it comes to dealing with many ShibbolethFederations because of the tight coordination required to maintain presences in the shared domain.

At the moment, this doesn't leave much. It suggests that for the time being, an SP that wants to maximize its options is better off handling IdPDiscovery itself by managing this process on its own, essentially making a WAYF part of its application environment and handing control to it when necessary. This enables a very customized user experience particular to the set of IdPs that an SP knows it can accept assertions from, potentially reducing confusion for users. In conjunction with possible research into browser extensions that could coordinate the use of multiple cookies to cache the results of IdPDiscovery across a set of SPs, this may be the best solution for the time being.