Versions Compared

Old Version 44

changes.mady.by.user Marco Malavolti

Saved on

compared with

New Version 45

changes.mady.by.user Marco Malavolti

Saved on

Key

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

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

Index

  1. 148092135eduGAIN Connectivity Check 2
  2. Check performed on the IdPs
  3. Statuses and results
  4. Common reasons for check failure
  5. 148092135eduGAIN Connectivity Check 2
  6. Disable Checks
  7. User interface
    1. User interface parameters
  8. JSON interface
  9. GIT repository148092135
  10. eduGAIN Connectivity Check 2

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 following two different wayfless URL and the various HTTP redirects until the IdP Login page. The  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.

...

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

Check performed on the IdPs

The check executed performed by the service follows these steps:

  1. It retrieves the eduGAIN IdPs from eduGAIN Operator Team database via a JSON interface access API.
  2. For each IdP that it was not manually disabled by the the ECCS2 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"
    , the check
    1. );
    2. verifies the SSL certificate
    of the IdP,
    1. ;
    2. creates a Wayfless URL for
    each SP involved and retrieves
    1. two selected SP;
    2. tries to reach the IdP login page for both SPs without performing any authentication.

      It expects to find the HTML form with
    a
    1. username and password
    field
    1. 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. In At the end of the execution, the check script is run again for those IdPs that have not been checked failed the check due to a problem met with the headless webdriver and signals if there are problems Webdriver(Google Chrome) used and writes each problem on the log file.

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. 
  • 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
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.

...

  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 both the following regular expressions:
    1. pattern_username = '<input[\s]+[^>]*((type=\s*[\'"](text|email)[\'"]|user)|(name=\s*[\'"](name)[\'"]))[^>]*>';
    2. pattern_password = '<input[\s]+[^>]*(type=\s*[\'"]password[\'"]|password)[^>]*>';
  4. Verify that your robots.txt is not unintentionally disabling ECCS.

...

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:

...

User interface parameters

Parameter nameParameter descriptionExample
date
Show all the service results for a specific date
date=2020-02-20
reg_auth
Show all the service results for a specific Registration Authority
reg_auth=https://reg.auth.example.org
idp
Show all the service results for a specific Identity Provider
idp=https://idp.example.org/idp/shibboleth
status
Show all the service results for a specific Status:
  • OK
  • ERROR
  • DISABLED
status=ERROR
check_result
Show all the service results for a specific result of check:
  • Invalid-Form
  • Timeout
  • Connection-Error
  • No-eduGAIN-Metadata
  • SSL-Error
check_result=SSL-Error

Example:

JSON interface

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

...

Action Name (JSON)Parameter Name (JSON)Parameter DescriptionExample
  • 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
check_result

Returns all the service results for a specific result of check:

  • Invalid-Form
  • Timeout
  • Connection-Error
  • No-eduGAIN-Metadata
  • SSL-Error
check_result=SSL-Error
  • eccsresults
format
Formats the service results in a simple way
format=simple

...

GIT repository

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

...