The purpose of the eduGAIN Connectivity Check 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 web page (https://technical.edugain.org/eccs/). 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.
If this page does not answer to your questions or you need some more information about this service, please contact us on edugain@geant.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 is was not manually disabled by the eduGAIN Operations Team, the check creates a SAML Authentication Request message to send to the location of the first "SingleSignOnService" URL with binding "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" in SAML metadata for that IdP.
The SPs used for the check are "Test SP shib 2.4" (https://sp24-test.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 authenticatin request is not signed. Therefore, authentication request for any eduGAIN SP could be created because the SP's private key is not needed. - The SAML Authentication Request is sent and the IdP login page is retrieved by the check. 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.
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 (page in Federation, update link)(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)
Disable Checks
In cases where an IdP cannot be reliably checked, it might be necessary to disable the checks for an IdP.
On-line interface
The eduGAIN Connectivity Check web pages is available at: https://technical.edugain.org/eccs/
The tool uses following status for IdPs:
| Status | Color | Decription |
|---|---|---|
| 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). |
| Warning | Orange | The IdP most likely does not consume the eduGAIN metadata correctly or it hasn't does not return a web page that looks like a login form. A typical case that falls into this category is when an IdP returns a message "No return endpoint available for relying party" or "No metadta found for relying party". |
| 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. |
| Diasable | White | The IdP is excluded from checks because it cannot be checked reliably (see limitations below) affected by some problems that prevent them to consume correctly eduGAIN metadata. The "Last test results" column, when an entity is disabled, shows the reason of the disabling |
The eduGAIN Connectivity Check's administrator can disable checks for entities by changing the service database. This is useful because some Identity Providers use login methods that cannot easily/reliably be checked. Therefore such IdPs should be excluded from the checks.