Federated identity and Shibboleth

Through the Shibboleth architecture, a service provider can identify a user without having to maintain its own set of passwords.

I have written before about the cyberspace equivalent of needing to carry around a separate driver’s license for every state that you drive through. Fortunately, the various states have established a trust federation where a driver’s license issued by any state is valid throughout the country. But this is still not true when driving (or surfing) through cyberspace, where a user frequently needs to use different “licenses,” usually usernames and passwords, for different applications and services.

A sensible strategy to tackle this issue is to separate the functions of providing a computing service and identifying individual users. A service provider (SP) delivers some service to properly identified users. An identity provider (IP) issues users some electronic token they can use as an identifier in cyberspace.

Returning to our driver’s license analogy, the IPs are the Departments of Motor Vehicles in all 50 states, while an example of an SP is a rental car company that checks your license before renting you a car. In this case the functions of the SP and IP are fully separated.

The service provider still determines who is allowed to use its service, but it relies on separate identity providers to actually identify specific individuals (that is, maintain the usernames and passwords). This allows a user to use the same digital identity (the same cyberspace driver license) to access multiple services.

Fortunately, an open-source project named Shibboleth has been supporting and developing an architecture that supports this approach. (Bonus points to those who know the origin of the term Shibboleth: It comes from the first documented scheme to identify individuals, used over 3,000 years ago and described in chapter 12 of the book of Judges in the Bible.) When using the Shibboleth architecture, the SPs and IPs exchange secure identity information that allows the SP to know individuals requesting the service are authorized without needing to maintain its own separate set of passwords.

Just last month Fermilab turned on their first Shibboleth identity provider (using a commercial system relying on open-source software from a company called Gluu). This allows Fermilab users to use their Services password to log in to remote services that accept Shibboleth credentials. In particular, users who require long-lifetime digital certificates (to sign email or to run grid jobs) can now get such certificates from the CILogon facility run by NCSA at the University of Illinois using only their Fermilab Services password. You can read detailed instructions (login required) for this process.

As more Fermilab services are integrated with Shibboleth, Fermilab visitors will begin to be able to use the electronic identities from their home institutions to use various Fermilab services, while those with existing Fermilab identities will find their existing identity increasingly useful for remote services such as the network access provided by the EduRoam service. Eventually, we should all be able to discard the plethora of separate electronic identities we now require.

Irwin Gaines