Page tree

Versions Compared


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

In their daily lives federation Federation operators and eduGAIN experts are frequently asked , how to test access to a production federated service can be tested. A simple login test to a federated service requires a federated account at an organisation that is part of the federation/eduGAIN. However, on one hand commercial service operators normally don't have and normally don't received federated accounts in a national federation and eduGAIN. On the other hand, And even if they had a single account of their own or if they asked a real-world user to test, this would not be sufficient to thouroughly test federated login with multiple identities and different sets of attributes.

Setting up an own a SAML Identity Provider (IdP) and us this using it to test the own IdP its Service Provider (SP) would be ideal but is non-trivial and therefore in most cases too much effort. Using self-registration IdPs (e.g. and configuring them bilaterally with their Service Provider (SP) might be sufficient for development but as these IdPs are not part of eduGAIN, they don't allow federated login under real conditions from an eduGAIN IdP. Also, self-registration IdPs usually don't allow certain attributes (e.g. affiliation) to be set.

The eduGAIN Access Check solves most of the above-mentioned forementioned issues because it provides SP operators an easy way to test federated login for their eduGAIN service with test identities that have different attribute profiles.


The eduGAIN Access Check service exclusively allows creating test accounts for users who can receive challenge emails for contac contact email addresses listed in the eduGAIN metadata for a particular Service Provider. The test accounts can be used exclusively to access a single SP (for which a user proofed that he is administrator for). Authentication requests for other SPs are rejected.