This Wiki is available to view but is still under maintenance. PLEASE DO NOT EDIT THE WIKI UNTIL FURTHER NOTICE. We are attempting to restore missing edits which took place between Monday 8 and Thursday 11 April 2019, therefore the site is likely to be taken off line at any time. Updated 20:43 CEST 16 April 2019.
Page tree

Versions Compared


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


Please find below a list of eduGAIN member federations, a link to the joining instructions (if any) and a contact email address:


Contact Address

Joining Instructions


Not Available







Not Available


Czech Republic



Not Available





Germany  and


Not Available



Not Available






Not Available











The Netherlands



United Kingdom

If you have a relationship to one of the above eduGAIN member federations, please follow their guide or get in touch with them using the given contact address. As explained above, a service can join eduGAIN via any eduGAIN member federation that accepts it. In order to become available as an eduGAIN service, a service only has to join one single eduGAIN member federation.


In some cases a service is already available via eduGAIN without you knowing it. This is often the case for publisher services that were (in pre-eduGAIN times) often registered with many national federations. Therefore, some services are already published in eduGAIN. If your service already supports SAML login (i.e it uses a SAML Service Provider), it is recommended to first check that the Service Provider (SP) is not yet in eduGAIN. This can be checked by searching for the service’s domain name on the REFEDS MET service, which contains a complete lest of all federated services worldwide. If MET finds an entry for your service and if it lists eduGAIN as one of the federations that includes your service’s metadata, you might not have to register the service again. All that then remains to do is to check if the Identity Providers (IdP) of your target user’s organisation are also in eduGAIN. This can be check with the domain names of these organisations and the eduGAIN isFederated Check. If the majority of organisations of your service’s target group is federated but not in eduGAIN, it still might make sense in the short term to join a local federation .


Now that the registration application is under way, you might want to install and configure a Service Provider implementation, compatible with the SAML 2.0 specification. The two most popular implementations are:

  • Shibboleth Service Provider, (page not found) which is implemented and maintained by the Shibboleth Consortium. It’s the most common and popular SAML implementation in eduGAIN and it also includes most features relevant for eduGAIN. Therefore, this is generally the recommended SAML implementation to use. It works very well with Apache and IIS as web server. It requires root access because it requires the mod_shib web server module.
  • SimpleSAMLphp, which is implemented and maintained by Uninett. This PHP implementation of SAML is recommended only if PHP is already used. It does not require root access but to make use of federated login requires code changes in a PHP application.


Note: It is not recommended to try creating an own SAML implementation. SAML is a very complex standard and trying to come up with something on your own, most certainly will cause interoperability issues. Generally, eduGAIN’s Web SSO profile (page not found) requires a SAML Service Provider to support the SAML2int profile.


Attribute Availability

The eduGAIN Attribute Profile  (page not found)contains a list of There are not recommendations from eduGAIN as to which attributes that eduGAIN Identity Provider should be able to release about their users. Attributes are however also generally not released by default. Typically, Identity Providers only release those attributes that are requested (as in the SP’s metadata) by a Service Provider.


  • Data Protection Code of Conduct (CoCo)
    The Data Protection Code of Conduct (CoCo) basically is a promise by the Service Provider to follow the EU data protection law. It gives Identity Providers the sometimes necessary confidence to safely release release attributes to Service Providers that are operated in the EU. Detailed instructions on how your Service Provider can support the Code of Conduct can be found here. Basically, it means writing a data privacy statement (examples are references on the wiki page) and then adding a special entity category value to the metadata of your SP.
  • REFEDS Research and Scholarship (R&S)
    In the same manner, the REFEDS Research and Scholarship (R&S) Entity Category is used  to support the release of attributes to Service Providers meeting a set of predefined requirements. Basically, if you are registering a Service Provider for a research community, then you are likely to get the R&S entity category if you request it. Details about supporting REFEDS Research and Scholarship can be found here.