...
The discovery service is a solution to the [IdPDiscovery] problem. Briefly summarized, it seeks to solve the problem that an SP has when a user first approaches it:
...
If the SP knows that only one IdP will ever provide authentication then it can immediately send the user to that IdP. However an SP will usually be able to handle users authenticated by multiple IdPs and at that point it has no option but to ask the user to select an IdP, this work is usually done by a [IdPDiscovery] service DiscoveryService.
Although this solution is deceptively simple it is complicated by several factors: *
- Any user interaction associated with this operation will be the first that the user ever sees and hence will define the user's opinion of the SP.
...
- Even returning users may not be aware of precisely what is being asked of them ("What is a Federation?", "What is an IdP?", "Why do I need to do this?")
...
- An independent service is not well positioned to provide simple choices because it has to make broad assumptions as to which IdPs might be of interest. This has two potential side effects:
...
- It will offer a confusing list of IdPs to the user
...
- It can allow a user to select an IdP which cannot provide authentication to the SP.
...
- SPs are very often members of more than one Federation
These issues can be minimized by associating a discovery service with each SP. Thus deployed the discovery service can: *
- Have a similar look and feel to the rest of the SP.
...
- Provide assistance in selecting the IdP in a way which is targeted at its particular users base.
...
- Limit those IdPs which the user is asked to chose from to those which the SP is willing to accept authentication from (for commercial, technical or other reasons).
In addition to per-SP discovery services, most federations deploy a discovery service. This serves as the 'back stop' service. It is considered best practice that SPs have a specific discovery service, however those SPs which are only in one Federation can rely on this Federation-deployed discovery service.
...
As an example, consider a commercial SP with contracts with three institutions: Institution A is a member of [InCommon], Institution B is a member of the [UK federation|http://www.ukfederation.org.uk] and Institution C is a member of the [Switch Federation|http://www.switch.ch/aai]
When a user approaches the SP, they should not be presented with a list of all the IdPs known to all three Federations, as the SP only needs to know which of these three IdPs the user needs to be sent to. The SP can provide guidance to the user in selecting one of these couched in terms that their target audience can understand.
...
In Shibboleth version 1.3, the discovery service takes an [AuthnRequest] message as input and, as a result of interaction with the user, forwards this message on to the selected [IdP]. IdP.
In Shibboleth version 2.0 the discovery Service can also handle the Discovery Service Protocol
The discovery service can keep track of the IdP that was selected by using the browser cookie specified in the [Identity Provider Discovery Profile|http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf]. However this can only store the fact that an IdP was selected, not whether the user authenticated successfully (in which case the user might wish to change their choice of IdP). Hence, by default the discovery service does not automatically redirect the request to the last selected IdP, instead a list of the most recently selected IdPs is provided as a hint.
...