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.
If you have to handle users from multiple IdPs, you need to have a Discovery Service in place.
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 theshibboleth2.xml
.<SSO entityID="https://aai-demo-idp.switch.ch/idp/shibboleth"> SAML2 </SSO>
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="https://wayf.switch.ch/SWITCHaai/WAYF" > SAML2 </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 configuration. |
||||
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. |