Discovery Service (DS) solves the discovery source inference problem. It finds out which identification source (Identity Provider - IdP) can identify the user and provide the most suitable personal information about him. Usually this is the identification service of the user's own home organization. Some users may have a user sccount in more than one home organization.

Traditionally, user identification starts when the user (the user's browser) arrives at the service (Service Provider - SP). At this point, the service does not know what the user's home organization is. Determining the user's home organization based on the IP address of the browser is possible, but not comprehensive, because the user may access the service from a place other than his home organization's address. The user's browser does not provide the service with information that would allow the user's identification source to be determined.

Haka's centralized DS service (formerly WAYF) is maintained by CSC and can be found at:

Configure this address in the Service Provider settings if you want to use the centralized WAYF/DS service.

User preference

User may store the preferred Identity Provider in a browser cookie for later use to bypass the selection.

If the user wishes to remove the preferred selection it can be done by visiting https://haka.funet.fi/DS/


Additional information

Centralized  Discovery Service

Along with other SAML specifications, the standardization consortium OASIS has published its own profile on the inference of the identification source. "The profile defines a general browser-based protocol that can be used to implement a centralized Discovery Service separate from the service, with which the unique identifier of the identification source capable of identifying the user can be handed over to the service requesting login." [1]

The service defined in the profile is also known as WAYF - Where Are You From. The centralized reasoning service in the Haka trust network is maintained by CSC.

The figure shows the route defined in the profile from the service to the identification source via DS.

  1. The service directs the user to the identification source inference service
  2. DS returns to the service the EntityId of the identification source specified by the user
  3. The service checks the address of the authentication source in its SAML metadata and directs the user to the authentication service

As is generally the case with SAML technology, also in connection with DS, information is not transmitted directly between the service, the inference service and the identification source, but the information is transmitted in the user's browser. In the steps described above, the user moves forward in the process with redirections (HTTP-Redirect).

Problems of the centralized Discovery Service

The Discovery Service (WAYF/DS) is a widely used technology that is usually produced centrally in the trust network. However, its use is not problem-free or appropriate in all situations. For example

  • The authentication-based service allows access from only one or a few authentication sources, but the centralized Discovery Service of the trust network includes all authentication services of the trust network
  • The look and feel of the ordered Discovery Service differs from the look of a service that relies on identification, which confuses the end user. The user may not understand the role of the trust network in logging in.
  • The authentication-based service allows access from authentication sources that belong to different trust networks
  • A visit to the centralized Discovery Service causes the user to make one or more extra clicks, which represents poor usability design

There is an example of the last two points in the attached picture, which shows the steps of logging into the Moodle service of the University of Turku using the Discovery Service of the Kalmar Union

  1. The user selects a login method from several different options on the front page of the service.
  2. In the reasoning service, the country whose federation is used is first selected
  3. After this, you choose your own home organization
  4. The actual login is done in the identification service of your home organization
  5. The user is finally directed to the service as a logged in user

Susceptibility to phishing attacks is also highlighted in the multi-step identification source deduction. Logging in always takes place in the home organization's identification service. The organization's usernames may not be given anywhere else. With the many stages of logging in, the user may be tempted to give his ID to a fake service that attracts with the ease of logging in.

Ignoring the Discovery Service

The discovery service can be bypassed by directing the user's browser directly to the desired identification source. This is done with a specially formatted link to an endpoint reserved for the purpose of the SP or IdP. T

The login link can refer to the SP, in which case we speak of SP-initiated login, or to the identification source, in which case we speak of IdP-initiated login. This login method has been introduced SAML-profile [2] designated as an  'Unsolicited Responce'. Based on the common SAML profile of the  Public Administration SAML-profile [3] used by the Haka, the SP (MUST) support this login method.

With login links, a link list can be implemented on the front page of the service, where by clicking on the link you can choose which home organization's identification source you want to log in with.  The method can also be used, for example, by redirecting subdomains where the address https://orgA.service.tldn/ redirects to the identification source of organization A and the address https://orgB.service.tldn/ redirects to the identification source of organization B

The login link is implemented by adding as attributes the entityId of the home organization's identification source and the address to which the user wants to be directed after logging in.

The following is an example of an SP-initiated link for the Shibboleth product, which is used to log in to the attribute test service with the IdP of Haka's test service:

The following is an example of a corresponding IdP-initiated link:

Finding the identification source embedded in the service

The Login links presented above can be generated programmatically in the application. They are usually used in services that need to be logged in with only a few identification sources. Therefore, their maintenance is often manual work. Manual work can be avoided by using applets developed for the purpose.

The inference of the identification source can be embedded in the service with javascript applets. A script is added to the front page of the service, which brings the reasoning service to the front page. From the user's point of view, the inference service is part of the actual service and he goes to the identification source directly from the service.

The Shibboleth project's Embedded Discovery Service (EDS) is an independent component that can be added to a page.

Embedded inference services rely heavily on the new metadata MDUI elements, which improve the usability of the inference service.

Shibboleth Embedded Discovery Service (EDS)

The inference service embedded in Shibboleth works most naturally as part of the Shibboleth SP software. The SP has an end point ready, from which EDS receives information about detection sources. EDS uses the same SAML metadata as the SP software. The selection list of EDS therefore includes all those and, on the other hand, only those identification sources with which SP has a credit relationship. This is useful when the SP only trusts some of the federation's identity sources, or it has established a trust relationship with third-party identity sources in addition to the federation.

Shibboleth EDS is independent of external services. It only needs an SP to work, from which it downloads metadata from detection sources.

More detailed information about EDS and how to install it can be found at this link: https://shibboleth.atlassian.net/wiki/spaces/EDS10/overview

Haka-EDS

Haka's centralized Discovery Service can also be embedded on the service's page. More instructions täällä.

Seamless Access Service (Edugain)

https://seamlessaccess.org/

https://seamlessaccess.atlassian.net/wiki/spaces/DOCUMENTAT/pages/84738141/Discovery+Service+Integration

Other considerations 

New services offer new opportunities that can be seized when the SP service is developed. New options are also acceptable to consider when establishing a new service.

the requirement of the public administration SAML profile to add the Discovery Response URL to the metadata if the centralized inference service is used. In this way, the centralized inference service checks the URL provided to it from the metadata. This limits the possibility of certain types of phishing attacks.

The administrator of the Haka identification source can promote the operation of new inference services and make his organization more visible by entering the MDUI data from his identification source into the Haka resource register.

References

  1. Oasis, Identity Provider Discovery Service Protocol and Profile
  2. Oasis, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0
  3. SAML 2.0 protocol deployment profile
  • No labels