Discovery

A Discovery Service is also known as „WAYF“ - „Where are you from?“. It establishes the connection between a Service Provider and an Identity Provider via a browser-based selection of the home organization.

There are three ways Discovery can be realized:

• An SP is configured to redirect to a central public Discovery Service, e.g. one that is run by a federation operator.
• An SP runs an Embedded Discovery Service itself.
• An SP is configured to redirect to one static Identity Provider (no Discovery Service in the proper sense, a.k.a „WAYFless URL“).

We run public Discovery Services that can be used by SP operators. These Discovery Services fetch information about available IdPs from the current metadata for DFN-AAI, DFN-AAI-Test, and eduGAIN.

• For Shibboleth SPs, the integration is documented on the page about Production.
• For SimpleSAMLphp SPs, please refer to their documentation, parameter discoURL.
• To use the Discovery Service in our test federation, please use the URL https://wayf.aai.dfn.de/DFN-AAI-Test/wayf.

An Embedded Discovery Service (EDS) is run locally on the SP. It also relies on federation metadata to get an up-to-date list of the available IdPs.

In many cases, an EDS is more user-friendly than redirection to a central Discovery Service:

• The selection of home organizations can be designed in the look and feel of the Service Provider. Users are not confused by being rediected to a site that looks completely different.
• Many SPs are not open to all IdPs in the federation because the SP operators only collaborate with a few home organizations. It can thus be misleading if users of other institutions can select their home organisation although they cannot log in to the service. With an Embedded Discovery Service, SP operators can filter the IdP list accordingly. Therefore, we recommend to run an EDS for Service Providers working with a limited amount of IdPs.

Shibboleth SP comes with a Discovery Service: Shibboleth EDS. The configuration is described on the Shibboleth SP page (in German). For background information please consult the Shibboleth Wiki.

With WAYFless URLs, a Service Provider triggers an Authentication Request with a specific Identity Provider. In this case, only users of that one home organization can access the service.

The configuration of WAYFless URLs often is SP-specific. It depends on the implementation of login on the SP if WAYFless URLs can be used and what they look like. Here are some best practice links:

• Best Practice: WAYFless Access to Resources - Configuring on a Service and Using in a Portal (very detailed)
• Best Practice recommendations of the US federation InCommon (Best Practice #2)

Some SP operators have documented the generation of WAYFless URLs for their platform:

• DFNconf and DFN-Webconf (in German)
• Elsevier
• Springer Nature
• List of Service Providers in the UK federation, also applicable for DFN-AAI as URL configuration does not depend on the federation

On a Shibboleth SP a WAYFless URL has the format. <RESOURCE-LOCATION> is the protected URL.

https://<FQDN_SP_HOST>/Shibboleth.sso/Login?entityID=<ENTITYID_IDP>&target=<RESOURCE-LOCATION>

With SimpleSAMLphp a WAYFless URL looks like this by default. <AUTH_ID> is the name resp. the ID of the authentication source (type: saml:SP), in general default-sp.

https://<FQDN_SP_HOST>/simplesaml/module.php/core/as_login.php?AuthId=<AUTH_ID>&ReturnTo=<RESOURCE-LOCATION>&saml:idp=<ENTITYID_IDP>