Introduction

If you're a service operator (provider of resources to the academic and research community) and are looking for a way to allow higher education users to authenticate to your service via federated access, you find on this page the relevant steps that describe how a service can be integrated with eduGAIN as a SAML Service Provider.

This page’s target audience is technical people (i.e. administrators) of organizations or communities that operate the service. Examples of organizations and communities that typically are interested to operate a service in eduGAIN are:

• research communities (i.e. international research projects)
• e-journal content providers (i.e. publishers)
• cloud service providers (i.e. suppliers of research projects)

This page is for service providers who want to offer their SAML-enabled services to users and institutions in several countries. Thanks to the advantages of eduGAIN, such services can connected to the identity federations of more than 50 countries around the world with scalable efforts. Joining a single eduGAIN member federation allows the users from all other eduGAIN member federations to potentially also access your service (if you allow that). This minimizes the technical and contractual work considerably. If you are interested in a verb brief introduction of eduGAIN in form of a video, please have a look at the About eduGAIN web page.

So, if you're a service operator (provider of resources to the academic and research community) and are looking for a way to allow higher education users to authenticate to your service via federated access, you find on this page the relevant steps that describe how a service can be integrated with eduGAIN as a SAML Service Provider.

This rest of this page’s target audience is technical people (i.e. administrators) of organizations or communities that operate the service. Examples of organizations and communities that typically are interested to operate a service in eduGAIN are:

• research communities (i.e. international research projects)
• e-journal content providers (i.e. publishers)
• cloud service providers (i.e. suppliers of research projects)

Once you have read this page and followed its instructions, you will have deployed a SAML2.0 compliant Service Provider and published it in eduGAIN. This means that a few million higher education users (students, university staff and faculty, researchers) can - depending on the access control rules you define - get access to your services using their home institutions account.

...

• Enables trustworthy exchange of identity information between federations without many bilateral agreements
• Reduces the costs of developing and operating services
• Improves the security and end-user experience of services
• Enables service providers to greatly expand their user base
• Enables identity providers to increase the number of services available to their users

Limitations

Please note that eduGAIN currently provides web-based authentication only on a large scale. This means that for federated login, almost always a web browser is involved at the user’s. eduGAIN itself also allows non-browser login via the SAML ECP profile. This profile is however hardly deployed yet by the eduGAIN Identity Providers. Therefore, it is usable only in very few scenarios.

• end-user experience of services
• Enables service providers to greatly expand their user base
• Enables identity providers to increase the number of services available to their users

Limitations

While eduGAIN provides many benefits for service operators, organisations and users, there also are a few limitations that a service operator should be aware ofeduGAIN is a world wide infrastructure that has been operational since 2011. As such it also has a few issues that you should be aware of:Despite the large number of participating countries and organisations, there are still some countries and organisations missing because they don’t offer federated login for their users or because they only offer federated login in their national federation but not (yet) in eduGAIN. With so many involved countries and organisations, coordination and setting standards for all participants is challenging. Also for example because countries typically have different data protection laws and other regulations. This, as well as deployment issues in some countries sometimes results in insufficient release of user attributes from participating Identity Providers. Also, there is no global standard for assurance levels of authentication or user attributes. Because national federations and organisations in general make use of the same user data that is used for enabling access via eduGAIN, it is also in their self-interest to keep user data up-to-date and properly verified. Think of a university that certainly is interested to properly identify their staff members and students before they join the university and get a user account. The same university also is interested to disable an account if a staff member leaves or student finishes his studies after some years.

Joining eduGAIN

The publication in eduGAIN, for a Service Provider allows reaching a large audience of higher education users (students, researchers, staff of higher education institutions) without the technical and administrative difficulties of maintaining and protecting repositories of user credentials. This is because authentication is always handled directly at and by the user’s home Identity Provider, while the Service Provider only has to deal with user Authorization. In Identity and Access Management, authentication is the process of confirming a user’s identity, usually by verifying the knowledge of a set of credentials (username, password). Authorization is the process of determining the access rights an authenticated user is eligible for. In eduGAIN terms, this would mean that a user accesses the Service Provider with an assertion of his identity and the Service Provider trusts that assertion because it comes from a trusted relying party, but it is always the Service Provider that decides to which parts of the service this authenticated user should have access.

...

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

...

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

Please read section 4.2 (Installation & Configuration), which contains detailed instructions for the installation and necessary configuration of a Service Provider, using one of the aforementioned implementations. Also make sure that, once installed, the Service Provider is tested using the SAML implementations sanity checks (e.g. for Shibboleth running "shibd -t" on linux) to ensure that the software was correctly installed. Ideally, the Service Provider is also tested against a SAML2 Identity Provider to ensure that it was configured correctly.

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.

...

Once the Service Provider software is installed, configured (see section 4.2) and functional, the next step is to register the Service Provider with the UKAMF federation.

Before completing the following form, please also read the section 4.2.4 about SAML2 metadata and how to generate/compose it for your Service Provider.  Then provide the request data and submit the form:

...

<iframe src="https://gn4-ssprp.aai.grnet.gr/" width="700" height="900930" name="Metadata Submission" style="border: 0;"></iframe>

...

• For a Shibboleth Service Provider please refer to their instructions provided in:
  http://www.ukfederation.org.uk/content/Documents/Setup2SP

Attribute Availability

The eduGAIN Attribute Profile 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.

...