The Embedded Discovery Service (EDS) provides a consistent user experience for the discovery part of Simple Sign On (SSO).
In order to initiate SSO, the user has to select where (with which Indntity Provider - IdP) they wish to be authorized. Many mechanisms have been used to solve this problem for instance:
- Typing in an associated URI.
- Hard-wiring in one or a few IdPs.
- Centralized discovery.
This last has been commonly used with Shibboleth SPs and in other situations where there is a a large number of IdPs. It consists of redirecting the user to a central location (the Centralized Discovery Service of CDS) which they are presented with a choice of all potential IdPs. This has usability issues:
- The user may be presented with, and then select, an IdP that the SP has no relationship with. The user may then log in sucessfully to the IdP, but still fail to get access to the SP. This leads to confusion.
- The CDS will almost certainly have a different 'look and feel' from either the SP or the IdP. In usabiloty testing this has been shown to be a massive barrier to progresing the logging-in process.
- There is no provision to allow favored IdPs to be presented.
EDS consists of JavaScript files that are be used to create a discovery service with an existing webpage. This can then be
- Branded so that the user can seamlessly move from Sp to Discovery to the IdP
- Restricted to only show those IdPs that the SP has a relationship with.
- Configured to preferentially present favored IdPs
The EDS is designed to be branded. Nonetheless SPs running the same EDS will present the same look and feel for discovery. This reduces confusion when a user encounters discovery.