Versions Compared

Old Version 32

changes.mady.by.user Marco Malavolti

Saved on

compared with

New Version Current

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. eduGAIN Connectivity Check 2Introduction
  2. Check performed on the IdPs
  3. Statuses and Resultsresults
  4. Common reasons for check failure
  5. LimitseduGAIN Connectivity Check 2
  6. Disable Checks
  7. User interface
    1. User interface parameters
  8. JSON API interface
  9. GIT repository
  10. Presentations
  11. FAQ - Frequently Ask Questions
  12. Usage statisticseduGAIN 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 public eduGAIN Connectivity Check 2 web page (https://technical-test.edugain.org/eccs2eccs/). 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 the various HTTP redirects until the user login form. The expected result is a login form that allows users to authenticate themselves (typically with username/password) or an error message of some form. For those Identity Providers that output return 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 onat support@edugain.org.

[Index]

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 eduGAIN Operations Team, the check 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 fieldthe ECCS script:
    1. doesn't check disabled IdP (added manually by an eduGAIN Operations Team via Python dictionary or dynamically by the IdP administrator via "robots.txt");
    2. verifies the SSL certificate of the SSO HTTP-Redirect endpoint used;
    3. creates the SAML Authentication Request for two selected NREN SP and for a random generated fake SP;
    4. tries to reach the IdP login page for all SPs without performing any authentication.

      It expects to find an HTML form with username and password fields in the answer. Therefore, no complete login will happen at the Identity Provider because the check stops at the login page or at SSL validation.
      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
    authenticatin
    1. authentication request sent is not signed. Therefore, an 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 failed the check due to a problem with the headless Webdriver(Google Chrome) and writes each problem on the log file.

[Index]

Statuses and results

The tool uses the following statuses for IdPs:

"" shows
StatusUI ColorDescription and results
ERRORRed
  • The IdP's response contains an HTTP Error 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)is not returned due to a Timeout, Connection or IdP Generic error.
    • Timeout: considers
    • Invalid-Form: considers those IdPs that do not load a standard usernamestandard 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 secondspage within 60 seconds.
    • Connection-Error: considers those IdPs that are not reachable due to a connection problem. View the Page Source content to discover which problem has the IdP.
    • IdP-Generic-Error: considers those IdPs that the returned web page does not contain a Login Form, but an unspecified error such as "An error occurred". This kind of error has been seen on Microsoft ADFS based IdPs.
    • 403-Forbidden: considers those IdPs that return 403 Forbidden status code while opening their login page through a testing SP.
  • 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-SP-Metadata-Error: considers those IdPs that return a message like "No return endpoint available for relying party" or "No metadata found for relying party"
    :
    • No-eduGAIN-Metadata
    • instead of the Login Page.
  • The HTTP SSL certificate used by the IdP is invalid (see below for further explanation)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.

  • OK
UNKNOWNYellow

The IdP can't be checked because the returned Login Page content is not recognized or the Login Page is always returned, also for the fake SP.

  • Unable-To-Check: 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".
DISABLEDWhite

The IdP is excluded because it cannot be checked reliably. The

Page Source

column, when an entity is disabled,

is populated with the reason for the disabling.

...

  • DISABLED: considers those IdPs that are disabled from the check by an eduGAIN Operation Team member or "robots.txt" file.

[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 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 the following regular expression:
    1. pattern_password = '<input[\s]+[^>]*((type|name)=\s*"password|email|user|text|name"|password|email|user|text|name)[^>]*>|<form[\s]+[^>]*(action)=\s*"/idp/module.php/multiauth/selectsource.php"[^>]*>';
  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 Account Chooser Authentication or X.509 login)
  • IdP does not allow requests coming from the ECCS servers: technical-test.edugain.org / technical.edugain.org
  • IdP that uses more than one nested <iframe> inside the 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:

User-agent: ECCS
Disallow: /

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 2 test Service web pages page is available at: at https://technical-test.edugain.org/eccs2eccs

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
  • UNKNOWN
status=ERROR
check_result
Show all the service results for a specific result of check:
  • OK
  • Timeout
  • Connection-Error
  • IdP-Generic-Error
  • No-SP-Metadata-Error
  • SSL-Error
  • Unable-To-Check
  • 403-Forbidden
  • DISABLED
check_result=SSL-Error

Example:

...

...

...

[Index]

API

...

interface

The eduGAIN Connectivity Check service 2 provides a JSON feed on has an API interface that provides access to the monitoring results in JSON format.

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

https://technical-test.edugain.org/eccs2eccs/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/eccs2eccs/api/##ACTION##?##PARAMETER##=<value>

Action Name (JSON)Parameter Name (JSON)Parameter DescriptionExample
  • eccsresults
  • fedstats
date
Returns all the eduGAIN Connectivity Check service results for a specific date.
date=2020-02-20
  • eccsresults
  • fedstats
reg_auth
Returns all the eduGAIN Connectivity Check service results for a specific Registration Authority.
reg_auth=https://reg.auth.example.org
  • eccsresults
idp
Return the eduGAIN Connectivity Check service result Returns the service results for a specific IdP by its entityID.
idp=https://idp.example.org/idp/shibboleth
  • eccsresults
status

Returns all the eduGAIN Connectivity Check service results for a specific Status:

  • OK
  • ERROR
  • DISABLED
  • UNKNOWN
status=ERROR
  • eccsresults
check_result

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

  • OK
  • Timeout
  • Connection-Error
  • IdP-Generic-Error
  • No-SP-Metadata-Error
  • SSL-Error
  • Unable-To-Check
  • 403-Forbidden
  • DISABLED
check_result=SSL-Error
  • eccsresults
format
Formats the service results in a simple way
format=simple


Example URL:

[Index]

GIT repository

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

...

edugain/eccs

[Index]

Presentations

[Index]

FAQ - Frequently Ask Questions


  1. What does mean the color assigned to my my IdP?
    See the Status and Results table
  2. Why my IdP gets UNKNOWN(yellow) status with 3 OK?
    The problem seems to be that the IdP accepting the metadata of SP-s not included in eduGAIN.
  3. Where I can raise an issue or a request on the ECCS service's code?
    Directly on the GitLab Repository.
[Index]

Usage statistics

2022-2023

  1. eccs_gui_api_stats.csv: Statistics regarding the ECCS User Interface API
  2. eccs_new_api_stats.csv: Statistics regarding the ECCS WEB API
  3. eccs_old_api_stats.csv: Statistics regarding the previous version of ECCS WEB API
  4. eccs_wrong_api_stats.csv: Statistics regarding the wrong requests to the ECCS WEB API
  5. eccs_usage_stats.tar.gz: All usage statistics files

[Index]