Federations 101

The content of this training module is based on experiences in the deployment of federated access. It is intended for an audience who has little or no understanding of federated access. Below, some of the most frequently asked questions reported by federation operators are listed.

Motivation

Have you been asked any of these questions in the past? Do you have some of these questions yourself?

  • Institution XYZ just introduced Shibboleth. When will you follow?”

  • What is this Shibboleth all about?”

  • What is SAML?”

  • Are there any other federation technologies I need to know about?”

  • There is this cool new service recently announced by university XYZ – what do we need to do to get access?”

  • I have too many passwords everywhere, why can’t I use my university account?

  • Students prefer to do their research from home. But to access online journals, they must be physically in the library, using one of 3 kiosk PCs. Why is this so?”

In this training module, the AARC project wants to provide an answer to these questions. Aspects that will be highlighted include:

  • access to online resources and other services in higher education;

  • software needed in order to grant users access;

  • the role of federations in enabling access to online resources and services.

The module will also highlight the issues around IP-based authentication, and why federated access should be preferred and the benefits it brings.

How to enable secure access to content

Higher education institutions were among the first when the WWW became usable for everybody. Consequently, there has been a shift in the past 20 years towards providing services and resources online. Examples of services and resources for research and education include:

  • online books and journals provided by publishers
  • video conferencing services
  • large file transfer services
  • e-learning platforms
  • download sites for software intended for students and researchers

Often the providers of such services have commercial interests. Other providers may not be commercial but need personal information about the users accessing their services. It must be ensured that only students get access, or more generally specific groups of users entitled to use the services. Securing this valuable content used to be a major problem. The first attempt at securing it was by restricting the IP addresses of the institutions that could access the content. This would mean that users needed to be physically present in the institution’s network or use proxy/VPN solutions.

Whilst this worked in the past, it is not a viable approach in today’s world, where users move much more frequently. Remote access is a strong requirement and it is fairly simple to find information online on how to circumvent the IP address check. Second, an IP access restriction is an  “all or nothing” decision, so a restriction for e.g. “only students and not faculty” could not be expressed. Federated access and the underlying standard (SAML, Security Assertion Markup Language) has been the answer to these challenges.

Several years ago, the UK federation provider Jisc produced a 5-minute video to explain how federated access works. This video is still relevant to date and provides a high-level introduction to the subject.

Slides on the Introduction to Identity Management are available here:

A service provider, and an identity provider

Federated access involves two entities:

  • a service provider (SP) that ensures that the user is authenticated and protects the content against unauthorised access, and
  • an identity provider (IdP) installed centrally at an organisation, e.g. a university.

The IdP authenticates the users and issues signed and encrypted SAML assertions to the SP. This is why the IdP is sometimes called an “asserting party” and the SP the “relying party”. Thus, user authentication is not done at the content provider, but at the IdP which is the only component users give their credentials to.

So what is a federation?

In the SWITCHaai demo you can see that there is a third component in a federation, the discovery service (DS). If you have just some resource protected by a SP and one single IdP, there is no need for the user to select their IdP, i.e. to perform IdP discovery.

However, in your country there is most probably more than one institution (university, library, etc.) whose users want to use federated access. This is when federations come into play. Think of them as a collection of services and organisations within one country.

Essentially, a federation allows so-called “federated identity management” (also known with the acronym: fIdM). Where traditional IdM would only process users within an organisation (say a university), federated IdM broadens the picture. This means that

  • a student or staff member of federated university A
  • can use resources or services at federated institution B
  • does not need to register for a B account
  • but can simply use his/her university’s A account

The benefit is clear: Users need just one password, and they have to type it only once (single sign-on).

And what if the online resource is in a different country from my users?

Most countries in Europe and many worldwide have established national research federations. This is where eduGAIN comes into play. It is a so-called interfederation service developed and operated by GÉANT, under a series of projects financed by the European Commission. Via this interfederation service, eduGAIN users from one federation can access services in another federation.

This graphs shows the way the eduGAIN interfederation works:

And this 4-minute video by GÉANT brings it all together:

Establishing trust and a set of common policies, as well as common data protection principles, on a multinational scale is not trivial. The GÉANT Data Protection Code of Conduct for SPs is an important guideline in addressing data privacy and attribute release issues, and is being adopted by and increasing number of service and identity providers.

But what is Shibboleth then? Are there other technologies for federation?

Many institutions or decision makers identify Shibboleth (the product) as the technology to implement federated access. Although widely used in our communities, Shibboleth is only one of the open source SAML implementations available. There are actually a few popular SAML implementations used in academic identity federations, with Shibboleth being the most popular. The Shibboleth Consortium is responsible for the development of the Shibboleth SP and IdP as open source software, among others. Shibboleth has an extremely active community because it has been deployed by thousands of universities all over the world. Many enterprises, including publishing houses, have also deployed Shibboleth.

For more information about Shibboleth please visit the Shibboleth Consortium’s webpage at:

You may be interested to:

  • provide federated access to your services;
  • run an IdP to issue credentials to users to access services in the
    federation.

There are many available that can help you to do this. Of the most current ones, the U.S. InCommon tutorials are recommended:

You might also be able to find how-to’s from your local federations that explain how to set up Shibboleth software and join federations, or commercial support to help you set it up for your organisation.

Some other very good open source implementations are also available, specifically:

  • SimpleSAMLphp, a PHP based software, that can be configured as an IdP or SP. See https://simplesamlphp.org.

  • pysaml2 is a python toolkit for implementing SAML2 applications. The software is available on github.

And last but not least, OpenId Connect, the identity layer built on top of OAuth2, is gaining momentum as an alternative technology to SAML. Commercial entities and research infrastructures are moving to that.