!!! ALERT - THIS SERVICE IS UNDER TESTING !!!

Index

Introduction

The purpose of the eduGAIN Connectivity Check 2 is to identify eduGAIN Identity Providers (IdP) that are not properly configured. In particular it checks if an IdP properly loads and consumes SAML2 metadata which contains the eduGAIN Service Providers (SP). The check results are published on the public eduGAIN Connectivity Check 2 web page (https://technical-test.edugain.org/eccs2/). The main purpose is to increase the service overall quality and user experience of the eduGAIN interfederation service by making federation and Identity Provider operators aware of configuration problems.

The check is performed by sending a SAML authentication request to each eduGAIN IdP and then follow the various HTTP redirects. The expected result is a login form that allows users to authenticate (typically with username/password) or an error message of some form. For those Identity Providers that output an error message, it can be assumed that they don't consume eduGAIN metadata properly or that they suffer from another configuration problem. There are some cases where the check will generate false positives, therefore IdPs can be excluded from checks as is described below.

The Identity Providers are checked once per day. Therefore, the login requests should not have any significant effect on the log entries/statistics of an Identity Provider. Also, no actual login is performed because the check cannot authenticate users due to missing username and password for the IdPs. Only Identity Providers are checked but not the Service Providers.

The eduGAIN Connectivity Check 2 is configured to maintain a history of 7 days of the results collected.

If this page does not answer to your questions or you need some more information about this service, please contact us on support@edugain.org.

Check performed on the IdPs

The check executed by the service follows these steps:

It retrieves the eduGAIN IdPs from eduGAIN Operator Team database via a JSON interface.
For each IdP that it was not manually disabled by the eduGAIN Operations Team or by IdP administrator via "robots.txt", the check verifies the SSL certificate of the IdP, creates a Wayfless URL for each SP involved and retrieves the IdP login page.
It expects to find the HTML form with a username and password field. Therefore, no complete login will happen at the Identity Provider because the check stops at the login page.
The SPs used for the check are "SP Demo" (https://sp-demo.idem.garr.it/shibboleth) from IDEM GARR AAI and the "AAI Viewer Interfederation Test" (https://attribute-viewer.aai.switch.ch/interfederation-test/shibboleth) from SWITCHaai. These SPs might change in the future if needed.
The SAML authentication request is not signed. Therefore, authentication request for any eduGAIN SP could be created because the SP's private key is not needed.
In the end, the check is run again for those IdPs that have not been checked due to a problem met with the headless webdriver and signals if there are problems on the log file.

Statuses and results

The tool uses the following statuses for IdPs:

Status	UI Color	Description and results
ERROR	Red	The IdP's response contains an HTTP Error or the web page returned does not look like a login page. The most probable causes for this error are HTTP errors (e.g.: 404 error) Invalid-Form: considers those IdPs that do not load a standard username/password login page and do not return messages like "No return endpoint available for relying party" or "No metadata found for relying party". Timeout: considers those IdPs that do not load a standard username/password login page within 60 seconds. The IdP most likely does not consume the eduGAIN metadata correctly. A typical case that falls into this category is when an IdP returns a message "No return endpoint available for relying party" or "No metadata found for relying party": No-eduGAIN-Metadata The IdP has a problem with its SSL certificate: SSL-Error
OK	Green	The IdP most likely correctly consumes eduGAIN metadata and returns a valid login page. This is no guarantee that login on this IdP works for all eduGAIN services but if the check is passed for an IdP, this is probable.
DISABLED	White	The IdP is excluded because it cannot be checked reliably. The "Page Source" column, when an entity is disabled, shows the reason for the disabling.

Common reasons for check failure

Verify that you have a valid SSL certificate matching your IdP hostname and with a valid chain. You can test it yourself with the SSL Labs checker: https://www.ssllabs.com/ssltest/
An "SSL-Error" may be related to a missing update of the CAs used by ECCS. If you suspect that this is the case, please contact the eduGAIN support at support@edugaing.org.
Verify that the IP used by the client that is performing the checks, is permitted to reach your IdP: any firewall in-between must be configured to let pass TCP packets with:
1. source IP X.X.X.X, source port 1024-65535
2. destination YOUR-IDP-IP destination port 443

Verify that your IdP Login page contains a text that matches with both the following regular expressions:

pattern_username = '<input[\s]+[^>]*((type=\s*[\'"](text|email)[\'"]|user)|(name=\s*[\'"](name)[\'"]))[^>]*>';

pattern_password = '<input[\s]+[^>]*(type=\s*[\'"]password[\'"]|password)[^>]*>';

Verify that your robots.txt is not unintentionally disabling ECCS

Limitations

There are some situations where the check cannot work reliably. In those cases, it is possible to disable the check for a particular IdP.
The so far known cases where the check might generate a false negative are:

IdP does not support HTTP or HTTPS with at least SSLv3 or TLS1 or newer (these IdPs are insecure anyway)
IdP is part of a Hub & Spoke federation (some of them manually have to first approve eduGAIN SPs)
IdP does not use web-based login form (e.g. HTTP Basic Authentication or X.509 login)
IdP does not allow requests coming from the ECCS2 servers: technical-test.edugain.org / technical.edugain.org

Disable Checks

In cases where an IdP cannot be reliably checked, it is necessary to create or enrich the robots.txt file on the IdP's web root with:

User-agent: ECCS
Disallow: /

User interface

The eduGAIN Connectivity Check 2 test web page is available at https://technical-test.edugain.org/eccs2

User interface parameters

Parameter name	Example
date	date=2020-02-20
reg_auth	reg_auth=https://reg.auth.example.org
idp	idp=https://idp.example.org/idp/shibboleth
status	status=ERROR

Example:

https://technical-test.edugain.org/eccs2?reg_auth=http://www.idem.garr.it/&status=ERROR

JSON interface

The eduGAIN Connectivity Check service 2 provides a JSON feed on the monitoring results.

The table below describes the actions that can be performed by replacing "##ACTION##" in the URL:

https://technical-test.edugain.org/eccs2/api/##ACTION##

Action Name (JSON)	Action Description
eccsresults	Returns all the eduGAIN Connectivity Check 2 service results
fedstats	Returns all the federation statistics collected by the eduGAIN Connectivity Check 2 service.

The table below, instead, describes the JSON parameters that actions can use:

https://technical-test.edugain.org/eccs2/api/##ACTION##?##PARAMETER##=<value>

Action Name (JSON)	Parameter Name (JSON)	Parameter Description	Example
eccsresults fedstats	date	Returns all the service results for a specific date.	date=2020-02-20
eccsresults fedstats	reg_auth	Returns all the service results for a specific Registration Authority.	reg_auth=https://reg.auth.example.org
eccsresults	idp	Returns the service results for a specific IdP by its entityID.	idp=https://idp.example.org/idp/shibboleth
eccsresults	status	Returns all the service results for a specific Status: OK ERROR DISABLED	status=ERROR
eccsresults	format	Formats the service results in a simple way	format=simple

Example URL:

GIT repository

https://gitlab.geant.org/marco.malavolti/eccs2

Presentations

ECCS2 4 GN4-3 WP5 Hands-All Meeting.pdf

Page tree

eduGAIN Connectivity Check 2