This page is aimed at publishers that are looking for a way to allow higher education users to authenticate to their services via federated access, in particular via eduGAIN. This page describes the relevant steps for a service to be published as a SAML Service Provider in eduGAIN. The page’s target audience is mostly technical people (i.e. administrators) of publishers.
Having a service being part of eduGAIN has advantages for all involved parties, the users, the operators and the participating organisations. Some of these benefits are listed on the page Benefits of eduGAIN.
As publisher, having your service in eduGAIN has the main advantage that the service might not have to be registered with additional individual federations anymore. In order to allow users to access a service, so far publishers had to join each national identity federation individually. Each federation had its own (similar) rules and processes to legally and technically join the federation. This caused quite some overhead on all involved sides. That was not a one-time overhead but a recurring one because if for example the service’s certificate changed, this change had to be announced and propagated to each federation a publisher’s service was member of. In some cases, publisher services are registered in more than 20 national identity federations. Thanks to eduGAIN, it might be possible to be registered only in one single federation but still reach most users from all eduGAIN member federations.
Once you have read this page and followed its instructions, you will have deployed a SAML 2.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 potentially - depending on the access control rules you define - get access to your services using their home institutions account. Your service will not only know from which organisation a user is from (independent from his network location) but it may also retrieve further information about the user in form of attributes. Attributes can include an anonymous unique identifier up to name or email address if these are needed.
This document only explains the technical bits and pieces necessary to join eduGAIN. Any legal or licensing aspects between a publisher and a federation or a federated organisation (e.g. a university) are out of scope.
Before attempting to follow the steps below to register a service in eduGAIN, it is recommended to first get familiar with some key concepts of federated identity management, the basis of eduGAIN and all SAML identity federations. A comprehensive overview of material that you might want to have a look at is available at the AARC Federations 101 page.
If you don’t have much time and prefer audio/visual documentation, you might want to watch the 4 minute movie “How to benefit from interfederating through eduGAIN”.
If you want to see and try federated login in action, you might want to have a look at SWITCH’sAAI Demo, which demonstrates the concept of federated login.
This chapter offers detailed instructions on how a service can participate as a SAML Service Provider in eduGAIN.
If you are already participating in a national SAML-based identity federation, we recommend that you first check in which federations your SAML service is registered in. It may well be that your service is already part of eduGAIN without you knowing it. To check in which federations your service is, it’s best to look it up in the Metadata Explorer Tool (MET) which can be found at: https://met.refeds.org/
By entering your service’s entityID (e.g. https://fsso.springer.com) or domain name (e.g. “thomsonreuters.com”) in the search field, you get an overview of all services that were found and in which federations they are registered in.
There are two outcomes of this step:
If your service is part not of eduGAIN yet or not federated at all, we recommend you to first follow the guide How to Join eduGAIN as Service Provider, which explains step by step how to federate a service and add it to eduGAIN.
If your services is already in eduGAIN, please use the isFederated Check Service to see, if your customers are also in eduGAIN or not. Even though more than 35 national identity federations are part of eduGAIN, not all of their organisations (e.g. universities) are yet ready to participate in eduGAIN. This is mostly because they have not yet applied the technical configuration changes needed to participate in eduGAIN.
If too few of your customers are in eduGAIN yet, it might be still better to joining individual federations, though this is not recommended in the long term. If only few of your potential customers are not in eduGAIN yet, the process for them to join eduGAIN could be speed up if you inform firstname.lastname@example.org about the organisations that would be interested in your service but that are not ready yet for eduGAIN.
In order to allow users from Identity Providers (IdP) to login and use your service, you might need to adapt your IdP Discovery Service (i.e. the service that lets a user choose from which organisation he is from). If the tool presenting the list of organisation IdPs is limited to only few federations, specific IdPs or if your service does not have a Discovery Service at all, you can have a look at chapter E. (“Use a Discovery Service that supports Interfederation”) of How to offer a service in eduGAIN.
Once your service is registered and ready for accepting users via eduGAIN, you might want to find out which of your clients now could also access your service using federated login in addition to the other authorisation mechanisms (i.e. IP authorisation) that they have been using so far.
To identify such clients, the isFederated Check Service might again be used. Just enter the domain names of your customers and see which ones of them are not in federations that your service join but are in eduGAIN. This then would allow you to contact such organisations and let them know that they now also can access the service using federated login via eduGAIN in addition to IP authorisation only.