wiki:ServiceProviderFederation/LoginTest

Testing user access to applications/resources within the Service Provider Federation

Please see https://www.clarin.eu/content/creating-and-testing-shibboleth-sp for an introduction to this topic.

In sum,

  1. each CLARIN SPF SP and IdP need to know each other by consuming SAML metadata about that IdP, respectively SP.
  2. Furthermore, the IdP must release attributes to the SP, to help authorize and identify the user.

Whether or not this workflow works for a certain SP-IdP combination must be tested, since isses surface regularly, especially regarding the second step.

How to test an SP

For regular CLARIN SPF SPs: AAggregator

SPs can be configured to log the attribute sets released by the IdPs? that users used. This info is then sent to the AAgregator backend (without the attribute values, to preserve privacy). Please see https://github.com/ufal/clarin-sp-aaggregator to install.

  1. Log in with the IdP to be tested for any AAgregator-enabled SP, such as the LINDAT/CLARIN repository SP https://lindat.mff.cuni.cz/repository/xmlui/login .
  2. Please visit https://lindat.mff.cuni.cz/services/aaggreg/ (AAggregator web app), you can log in with any IdP for that.

Find the entry with the correct timestamp and IdP-SP combination. The report you see shows the attribute release (quality) for various recently attempted IdP-SP combinations. If too few attributes have been released, this can cause problems with our SPs. ‘Bad’ results, where attribute release quality is insufficient for normal CLARIN applications, are called out there. The results should then be studied with the SP operator, and if needed the IdP operator should be notified of the problem with a view to having the IdP release more attributes.

For SPs that consume SAML metadata about eduGAIN IdPs?

You can use https://access-check.edugain.org for testing authentication with different user profiles through "eduGAIN Access Check" IdP.

How to test an SP (for testers)

You will get tickets if people like you to test their SP with a detailed description on where to find the login to test. In case of an error, please provide the error to the SP that created the ticket. You can recall your willingness to test logins at any time. Keep in mind, the longer the list is, the fewer logins every person has to perform. To have testers for every country is an important task, on the way to ensure proper configuration of all SPs.

List of testers per country (i.e., identity federation)

We are looking for volunteers'''

Belgium

Czech

Denmark

Estonia

Finland

Germany

  • Thomas Kisler, Bavarian Archive for Speech Signals (e-mail: is up to date in user profile)
  • Oliver Schonefeld, IDS Mannheim (e-mail: is up to date in user profile)

Netherlands

  • Dieter van Uytvanck <Dieter Van Uytvanck>: Universiteit Utrecht

Norway

Sweden

Last modified 8 years ago Last modified on 07/05/16 15:35:20