What is Shibboleth? Or an identity federation? What about SAML? Am I an SP or an IdP? And how do they all work to protect electronic resources?

Shibboleth is one of the least understood authentication technologies in online publishing, encased in a variety of unfamiliar acronyms and often treated as a black box by publishers. However, it is also a core application for enabling institutional Single Sign-On (SSO) and offers some exciting possibilities for delivering an increasingly seamless and engaging user experience.

What is Shibboleth?

The name originates from a Hebrew term referring to a word whose variations in pronunciation can be used to tell different groups of people apart. In the context of authentication, it is a set of open source software tools that provide an implementation of SAML (Security Assertion Markup Language).
You might be familiar with Apache, which provides an implementation of an HTTP Server. Browsers like Internet Explorer, Chrome and Firefox all provide implementations of an HTTP client. As they all speak the same HTTP protocol, they can communicate.
Think of SAML like HTTP. It’s a set of standards that describe how a large organization’s single-sign-on service, or “identity provider”, can exchange user login information with any electronic resource, or “service provider”.
In practice, this means a student can log into their institutional library from anywhere in the world and get seamless access to all the library resources that support SAML. In the background, each resource contacts the library to find out who the user is. If they aren’t logged in, the library asks them to log in before returning them to the resource.

Why is it being used?

Institutions like Shibboleth because it provides them with more control over access to their resources.
IP ranges are blunt tools – everyone within the range gets seamless access, but those administering the institution’s electronic resource budgets have little understanding of who’s actually using what. This hampers their ability to allocate resources efficiently, something that’s particularly important when library budgets are constrained. And users accessing from outside this IP range, such as those using mobile devices via a cellular network or accessing from off-campus, have to authenticate regardless, and typically through a proxy server that can bring its own problems.
Implementing Shibboleth provides institutional administrators with the opportunity to understand exactly who is using what resource. If the institution already uses SSO for internal platforms, it also enables users to login using authentication details they are already familiar with – saving yet another set of credentials to learn.

User Privacy

An institution exchanges user information, or “assertions” in SAML parlance, with a publisher. It’s possible for this information to be rich and varied, but within an educational context a set of standard attributes called eduPerson is widely adhered to.
Many of these attributes are designed to provide a degree of privacy by providing each publisher with a unique identity for a user without giving away their real-world identity.
Each institution decides what attributes it will expose to each publisher. For maximum privacy, it might choose to expose attributes like eduPersonTargetedID – an entirely opaque identifier for a user that varies from resource to resource. Publishers can use this identifier to provide a customized experience for the user, without being able to identify them or build a broader profile of their usage across resources.

What is an identity federation?

A good starting point to understand identity federations is to consider a world without them.
In order for a publisher, or Service Provider (SP), to interact with an institutional customer, or Identity Provider (IdP), they need to trust each other. They do this by providing metadata like encryption keys and the URLs that can be used to send and request information.
With just one IdP and maybe a few SPs, you could exchange this metadata quite informally, based on personal trust, and install it into the Shibboleth software by hand.
But imagine hundreds of IdPs and SPs wanting to communicate. It would be a horrendous task to email each IdP every time an SP wanted to adjust something in their metadata.

federations1

This is where federations come in. A federation is just a big list of metadata entries aggregated from their member IdPs and SPs. Each federation will have policies on exact what kinds of organizations can participate, and set some quality standards on the metadata allowed in their published data.

federations2

As each federation member typically refreshes their copy of the federation metadata at least once day, any changes from one member are quickly propagated to all the others.

Do I need to join every federation?

Generally, IdPs join an appropriate national federation, e.g. InCommon in the USA or the UK Access Management Federation in the UK. If a service provider wants to communicate with an IdP, it needs to ensure its metadata is available in the same federation.
Sometimes this means joining the federation directly – historically, it’s not unusual for a provider to register itself in many federations directly.
However, the development of interfederation services like eduGAIN means metadata registered with one federation member will automatically propagate to the others. How effectively this works depends on the federations involved, but it’s certainly getting easier as time goes on.

How do I protect my resources with Shibboleth?

You can use the Shibboleth SP (Service Provider) software directly – this needs to involve both system administrators as well as application development teams. There’s a reasonable learning curve involved, and it helps to have a basic knowledge of how SAML works under the hood. If you need to deploy Shibboleth SP at scale across clusters of machines, you will certainly need to understand more about the technical underpinnings.
While the planning and implementation phase can be quite involved, the biggest problem is ongoing support. It’s difficult to keep a team ‘active’, so troubleshooting problems tends to be slow and relatively expensive. As a result, it is an expensive solution to support in-house.
Publishers should also provide institutional customers with WAYFless URLs that embed information to identify the relevant IdP (which may or may not be the same institution that students are affiliated with). This avoids having to redirect users to a WAYF (Where Are You From) page in order to select their IdP before continuing with the authentication process.
Of course, the best solution is not to have to worry about what’s in the black box.

We can help

Our API provides a simple authorization protocol. As a publisher, you integrate this once and can take advantage of any current or future authorization method, including Shibboleth. Use our service as much or as little as you want – you only pay for what you use.
For Shibboleth, we’ll work with you to register your metadata in the appropriate federations. Once registered, you can enable access for any federation member in seconds via our Publisher CRM.
Best of all, Shibboleth can stay as a black box and you can let others worry about the contents.

Learn more about our API, or contact us to find out how we can help you.