Discovery Service Options for SWITCHaai

If your SP accepts users from multiple IdPs, you need to configure a Discovery Service. This is an overview about the different options available and which option best fits which needs (slides). A Discovery Service is needed to let the user choose the IdP of his organization where he can authenticate.

0. Special case: Single IdP only

If you know that only one IdP will ever provide authentication then you can send the user directly to that IdP by setting the entitiyID of this IdP inside the shibboleth2.xml.

<SSO entityID="">

If you have to handle users from multiple IdPs, you need to have a Discovery Service in place.

1. The classic way: the central WAYF

The central WAYF was the first discovery service for the SWITCHaai federation. But it has been constantly improved and enhanced since 2005. When installing a Service Provider according to our installation and configuration guide, the WAYF is already configured in the shibboleth2.xml file with the following lines:

<SSO discoveryProtocol="SAMLDS"
	discoveryURL="" >
</SSO >

2. Direct Login URLs

Creating direct Login URLs for every IdP is a simple solution, but only scales for a handful of IdPs. Beyond that, it gets too laborious and error prone. You may use the Login Link Composer to generate direct login links. Use these links for login buttons, best by linking it to the organisation's logo.

3. SWITCH Embedded WAYF

There are several reasons why you could prefer the embedded WAYF over the central WAYF:
  • The look and feel of the central WAYF cannot be influenced, but the embedded WAYF is fully customizable.
  • Add and remove IdPs as you like. So you can only list these IdPs from which you actually allow users to access your services. This is especially useful for interfederation enabled IdPs.
  • integrate the discovery into your web page instead of redirecting the user to the central discovery page.

4. Shibboleth Embedded Discovery Service

The Shibboleth EDS is very simular to the SWITCH embedded WAYF. The only advantage is that EDS is not dependent on a central server. But the downside of having no central server is that you cannot cache the previously selected IdP across multiple service providers as their cookies have different domain attributes.

Comparison of different Discovery Service Options

Properties central WAYF Login URL SWITCH Embedded WAYF EDS
Independent from central server
The Embedded WAYF needs to load JavaScript from the
central WAYF which means your IdP list is
always up-to-date.
Display only "valid" IdPs for SP
The Embedded WAYF (when wayf_use_disco_feed = true;)
and EDS will only display IdPs for which they have metadata.
Search as you type feature      
Show Home Organisation Logo
For the Login Link you need to embed the logos manually.
Very easy deployment      
Can be used with older Shibboleth SPs (<2.4)
The wayf_use_disco_feed option cannot be turned
on, as those SPs do not support the DiscoFeed.
Categories supported
The Embedded WAYF supports a sorting into the following categories:"university", "uas", "hospital", "tertiaryb", "vho",
"others", "all". Categories can be switched on and off in the
Uses cached recent IdP selection
across different services
Thanks to the central WAYF which manages the cookie of
the user, the Embedded WAYF knows about recent IdP
selection, also for other services.