...
A more concrete guide with step-by-step instructions is provided by the page How to Join eduGAIN as Service Provider.
Requirements
What does it mean to operate an eduGAIN service
Operating an eduGAIN service means that a service can outsource user identity management and password management to the user's home organisation (e.g. university) that does this for their users. To make federated login via eduGAIN work, the service has to add support for the SAML protocol that sends the user to his home organisation for authentication and then redirects him back to the service together with some user attributes. Most services rely on the very popular Shibboleth Service Provider to initiate and perform the whole SAML login process so that the service itself has to only declare where a SAML session should be enforced (e.g. on directory /auth/login or when user clicks on a certain link) and then has to consume the user attributes provided by the SAML Service Provider in a reasonable way.
Instead of having users register first with your service by completing a registration from, a service can just force them to log in via federated/eduGAIN login and it then typically gets some information about the user (unique identifier, name, email, organisation, affiliation), which can be used to auto-provision an account in the service application if that is needed. One of the most important aspects that changes for the service: There are no username and password available anymore for the user.
In brief, offering a service as eduGAIN service has the following advantages:
- No need to deal with user password management anymore as this is done by the users' home organisation
- Account provisioning on the service can be automated based on the user's attribute
- Users from more than 40 countries and more than 3000 academic and research organisations can potentially access your service.
- The service of course still can fully control who can access the service implementing some access control based on the user's attributes
There are also a few disadvantages:
- The application does not get the user's username and password anymore. The username can be substituted with an attribute (unique identifier, email) sometimes.
- The service has to integrate and operated an additional component that does all the SAML protocol work
- If attributes are released to a particular service or not is controlled by the Identity Provider (e.g. university) of the user. It is not guaranteed that all attributes a service requests are released by the Identity Provider.
Requirements
The service to be enabled for federated login via Services to be enabled for eduGAIN should meet the following requirements:
- Web-based: The service should be a web application. Even though non-web profiles like the SAML ECP profile could be used in eduGAIN too, most Identity Providers in current identity federations (including) eduGAIN support web-based applications only.
- SAML Interoperabel: It is assumed that the service can be protected by a SAML Service Provider like Shibboleth or Simple SAML PHP. For many popular web applications there are plugins, modules or documentation available that explains how to achieve this. Just google for the product and "saml" or "shibboleth".
General Procedure
A. Service Registration
...