Open Menu Close Menu

Security

Mutual Trust

Federated Identity Management

Federated identity management initiatives like Shibboleth are helping create a seamless infrastructure for secure sharing of online resources.

Mutual Trust PROVING THAT AN INDIVIDUAL is who he says he is (authentication) and that he has the right to access the resources that he is trying to use (authorization) is at the heart of cybersecurity. All too frequently, however, these functions have been built into individual applications, resulting in myriad authentication and authorization schemes, each requiring unique passwords and user IDs. As a result, hapless users are forced to maintain lengthy lists of application passwords, in order to do their work.

The problem is particularly complex in higher education, where users routinely engage in collaborative activities with peers at other educational, governmental, and corporate institutions. Some of these collaborative activities, such as blogging, only require weak authentication. Conversely, activities such as federal grant management or access into an institutional financial system require strong authentication. Thankfully, the goal of federated identity management (IdM) is to allow a user from one campus (or organization) to perform a web-based single sign-on (SSO) at that campus and then transparently access resources residing at other institutions, if authorized to do so. According to Internet2 Senior Technical Analyst Nate Klingenstein, there are four points key to understanding federated IdM: 1) It leverages local identity to access remote resources; 2) organizations must trust each other; 3) it is highly decentralized; and 4) you can have federated identity without federations.

Shibboleth 101

Shibboleth, an initiative of Internet2, is an effort to develop an open source federated IdM system that meets higher education's research and education requirements. (A brief introduction to federated IdM and Shibboleth can be found in "Trend Report: Identity Management"; CT November 2005.)

The Shibboleth system is based on and conforms to both the Security Assertion Markup Language (SAML) standard (version 1.1) and Microsoft's Active Directory Federation Services (ADFS). This allows organizations using disparate authentication and authorization techniques to interoperate by creating a federated single sign-on, and attribute exchange framework that facilitates inter-institutional access and sharing of resources. In addition to supporting the SAML and ADFS standards, the Shibboleth implementation includes features targeted to the needs of higher ed, such as the management of privacy.

According to Steve Carmody, an IT architect at Brown University (RI) and project manager for the Internet2/MACE (Middleware Architecture Committee for Education) sponsored Shibboleth effort, the current release of Shibboleth (version 1.3.3) is very stable and is being used by a large number of campuses and service providers. Version 2 of Shibboleth is in the works and a final release is expected early this year. The new version will support the more interoperable SAML version 2 and is being developed by teams in the United States, Europe, and Australia.

How Shibboleth Works

ACCESSING A SHIBBOLETH-enabled resource is a four-step process:

  1. When a user attempts to access a web resource belonging to a remote institution, Shibboleth Service Provider (SSP) software queries the user for his or her home institution.
  2. The user's browser is then directed to Shibboleth Identity Provider (SIdP) software at the user's home institution. The home site uses a web sign-on method chosen by the home institution to authenticate the user.
  3. The user's web browser is then directed back to the SSP, along with an "assertion" from the home institution SIdP that the user is authenticated, and an appropriate set of attributes describing the user. One of those attributes might be that the home campus believes that the user is eligible to access the resource; another attribute might be the user's identity. (The home institution and individual user control which attributes are released to each SSP.)
  4. The SSP passes the user's attributes from the home institution to the web resource, which then uses those attributes to permit or deny access.

Mutual Trust

Carmody notes that Shibboleth has been adopted more rapidly in Europe than in the US. One of the reasons for this, he believes, is that Europe has been aggressive in developing national licenses for digital content (which requires some sort of federated IdM), whereas this country still generally negotiates licenses on the institutional level. But he says that adoption of Shibboleth in the US is accelerating, perhaps due to the creation and adoption of a common framework for trustworthy, shared management of access to online resources in support of education and research. That is the objective of the InCommon Federation, a trust federation that uses Shibboleth for access control. InCommon now has 47 higher education participants, 16 corporate members, and three national laboratories. Carmody predicts that as an increasing number of US schools adopt Shibboleth, there will be a growing case for vendors to make their applications compatible with Shibboleth—or "Shibbolize" them. He notes that there also is a growing use of Shibboleth to access applications supporting collaboration. The National Science Foundation, for example, recently funded Internet2 to work with existing virtual organizations to implement federated access to their collaborative environments.

Carmody also observes that Shibboleth is often adopted in a three-step process: First, a campus deploys Shibboleth as a web SSO system for intra-campus use. Second, by using Shibboleth to deliver appropriate campus attributes, application development can be simplified and auditing is improved. Third, the campus is ready when the first inter-campus application appears.

Case Study: Great Plains Network

Greg Monaco is executive director of the Great Plains Network (GPN), a consortium of 24 universities in eight midwestern states. While he recognizes Shibboleth as a campus single-sign-on solution, he feels that its power lies in bridging campus boundaries.

Monaco points out that like many new technologies, there is a "chicken or egg" problem with adopting Shibboleth. What is the impetus for an institution to use Shibboleth for authentication if it doesn't have any Shibboleth-capable applications? Similarly, why develop Shibboleth-capable applications if there isn't a federation in place to take advantage of them? To address this problem, GPN initiated an 11-institution Shibboleth trial that included researchers as well as technical support staff. The trial has expanded and GPN now hosts a Shibboleth-protected wiki and operates an identity server to grant identities to anyone from a non- Shibboleth-ready campus.

To encourage researchers to adopt the new identification scheme, GPN decided to make available a powerful set of bioinformatics tools developed at the University of Missouri. Missouri was willing to make those tools available to other universities in the consortium, but wanted a mechanism that allowed Missouri to retain access control while the user's home institution managed eligibility. Shibboleth appeared to be the perfect solution. Now, faculty and researchers from other campuses in the consortium can go to the University of Missouri website and access Missouri's bioinformatics tools through a server operated by GPN; the server then uses Shibboleth to obtain the necessary authentication and eligibility from the user's home institution.

Currently, three institutions in GPN use Shibboleth on their home campuses: Arkansas State University, the University of Kansas, and the University of Missouri. So far, says Monaco, GPN has found that the first time a campus sets up a Shibboleth Identity Provider (SidP) and Shibboleth-enables an application, it takes some time to set things up, but the next time around it is straightforward. And other than periodic software upgrades, ongoing maintenance is minimal.

Monaco notes one caveat: "Shibboleth is useful if you have a resource that you want to share with a broad community. But if there are only a couple of people at each institution sharing a resource, there are other solutions such as Globus, or an independent identity provider service like ProtectNetwork.org, that may be more appropriate." Still, he feels GPN has learned a great deal from its Shibboleth trial, and plans to continue working to support multi-university communities.

Case Study: University of Texas System

An early pioneer in federated identity management, in 2004 the University of Texas System joined the National Science Foundation Middleware Initiative-Enterprise and Desktop Integration Technologies Consortium. NMI-EDIT was funded by the NSF in 2001, with the objective to develop tools, software, and practices to support interoperable identity and access management infrastructures.

According to Clair Goldsmith, senior adviser for information technology at the UT System office, UT has focused on using Shibboleth for administrative applications spanning the 15-campus system, and now has more than 30 applications available using Shibboleth-based single sign-on. One of the first applications was to provide wireless access to campus visitors at the system office. UT's newest multi-campus application is the Forensic Assessment Center Network, which permits 4,000 case workers from the Texas Department of Family Protective Services to provide case data from pediatric emergency room visits to be analyzed by the faculty at the four UT medical schools.

Adoption of Shibboleth in this country is accelerating, perhaps due to the creation and adoption of a common framework for trustworthy, shared management of access to online resources in support of education and research.

Goldsmith says that the resources required to deploy Shibboleth were relatively modest. He and another individual (who worked part-time) set up policy, creating a multiinstitution governance structure, and preparing operational documents. A full-time technician was required for nine months to assist individual institutions in setting up their identity servers and provide training on the Shibboleth technology. Now that Shibboleth is up and running, the amount of time required to support the software has dropped dramatically.

Goldsmith notes that while Shibboleth works well with web-based applications, third-party applications that use proprietary authentication schemes frequently present challenges. For example, the Oracle PeopleSoft student information system is not Shibbolethcompliant. Individual campuses, such as The Ohio State University and Griffith University in Australia, have taken the lead in Shibboleth-enabling non-compliant applications.

Goldsmith stresses, however, that such technical standards, while challenging, are easier than developing the policy framework that allows multiple campuses to share resources. To help create a trust fabric between its institutions, the UT System followed a three-step process. First, a statement of direction was adopted that defined a set of standards and compatible technologies that UT CIOs agreed to support at their institutions. Then, in 2006 the UT System adopted a vision statement, which described what was to be achieved by adhering to the statement of direction. That vision was: "All University of Texas students, faculty, and staff are able to access both local and remote resources using their local credentials and attributes, through a seamless technology infrastructure." Finally, UT developed a detailed "Roadmap" to outline the tasks and milestones necessary to achieve the vision.

In addition to creating trust between institutions, Goldsmith also stresses the need for higher education to have a common framework between federations (for example, between the UT System and the Great Plains Network). Essential to such a framework are national standards. In that vein, the UT System has been an active member of the InCommon Federation, has built the UT System Federation to allow for future interoperability with InCommon, and has initiated interoperability discussions with InCommon.

-Doug Gale is president of Information Technology Associates, an IT consultancy specializing in higher education.

comments powered by Disqus