Versions Compared

Old Version 68

changes.mady.by.user Marco Malavolti

Saved on

compared with

New Version 69

changes.mady.by.user Marco Malavolti

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

[Index]

Check performed on the IdPs

...

  1. It retrieves the eduGAIN IdPs from eduGAIN Operator Team database via access API.
  2. For each IdP the ECCS script:
    1. doesn't check disabled IdP (added manually by an eduGAIN Operations Team via Python dictionary or dinamically by IdP administrator via "robots.txt");
    2. verifies the SSL certificate;
    3. creates a Wayfless URL for two selected SP;
    4. tries to reach the IdP login page for both SPs without performing any authentication.

      It expects to find the HTML form with username and password fields. 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 it will be needed.
      The SAML authentication request sent is not signed. Therefore, authentication request for any eduGAIN SP could be created because the SP's private key is not needed.
  3. At the end of the execution, the script is run again for those IdPs that have been failed the check due to a problem with the headless Webdriver(Google Chrome) used and writes each problem on the log file.

[Index]

Statuses and results

The tool uses the following statuses for IdPs:

StatusUI ColorDescription and results
ERRORRed
  • The IdP's response contains an HTTP Error or the web page returned does not look like a login page.
    • 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.
    • Connection-Error: considers those IdPs that are not reachable due to a connection problem. 
    • IdP-Error: the web page returned by the IdP does not contain a Login Form and reports an unspecified error such as "An error occured". This has been seen on Micrsoft ADFS based IdPs.
  • 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 HTTP SSL certificate used by the IdP is either invalid or has chain issues (see below for further explanation):
    • SSL-Error
OKGreen
  • 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.
DISABLEDWhite
  • 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.

[Index]

Common reasons for check failure

  1. 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.
  2. 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
  3. Verify that your IdP Login page contains a text that matches with the following regular expression:
    1. pattern_password = '<input[\s]+[^>]*(type=\s*[\'"]password[\'"]|password)[^>]*>';
  4. Verify that your robots.txt is not unintentionally disabling ECCS.

[Index]

Limits

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 ECCS servers: technical-test.edugain.org / technical.edugain.org
  • IdP that use more than one <iframe> inside their login page

[Index]

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:

...

If it is not possible to create the robots.txt under the IdP web root directory, the check can be disabled by an operator of the federation, where the IdP is a member, with an email to support@edugain.org.

[Index]

User interface

The eduGAIN Connectivity Check Service web page is available at https://technical.edugain.org/eccs

...

[Index]

API interface

The eduGAIN Connectivity Check has an API interface that provides access to the monitoring results in JSON format.

...

[Index]

GIT repository

https://gitlab.geant.org/edugain/eccs

[Index]

Presentations

[Index]