By Michael Schwartz

• Federated identity is a transformative technology that will turn higher education institutions into both identity consumers and identity providers.
• The ROI for federated identity will be derived from the institution's use of SaaS software, cloud providers, and new claims-based enterprise software like Microsoft SharePoint.
• Use of federated identity will enable people at institutions to do higher value transactions online, such as submit a grant proposal to a federal agency.
• Federated identity gives people more control over their privacy and personal security.

The concept of federated identity was recognized in November 2009 with the EDUCAUSE Catalyst Award, which honors IT-based innovations that provide groundbreaking solutions to major challenges in higher education. But what is federated identity? The gist is that federated identity enables a person's "user" information to be distributed on the Internet. This solves a common problem: the need to maintain a username at every website. In this paradigm shift, identity information is not stored within each website, but accessed on the wire as needed. Websites become "relying parties" (RPs) using the information of trusted "identity providers" (IdPs). Although it has taken a while, finally the recipe for federated identity seems clear. The ingredients are:

1. Protocols for authentication and attribute exchange — for example, Security Assertion Markup Language (SAML) or OpenID
2. Identity discovery — a system that can be used by websites to look up information about a person before they have authenticated, in order to figure out "where a person is from," for example their home institution
3. A trust model — a sometimes cryptographic method to establish the integrity of a person's information and the servers or tokens that electronically vouch for a person on behalf of an institution
4. A trust framework — an identity assurance mechanism that enables service providers to understand the quality of a person's credentials

Following is a discussion of the higher ed flavor of each of these ingredients.

Protocols

The challenge with federated identity protocols is that people tend to think protocols are the answer, when how they are used has been more of a challenge than their format. That said, there are many protocols to choose from: SAML, OpenID, OAuth, IMI and WS-Federation just to name a few. These protocols are available in a variety of releases. The most important federated identity protocol for higher education is SAML, an OASIS (Organization for the Advancement of Structured Information Standards) standard. SAML was the first federation protocol, and it has been shown to interoperate with a wide swath of software, including Microsoft's new claims-based security architecture.

SAML is the primary protocol supported by Shibboleth, which is becoming the ubiquitous federation software in the higher education community. Shibboleth is a project under the Internet2 Middleware Initiative, which is led by a group of U.S. and international higher-education IT architects. Shibboleth is not limited to SAML. As other protocols become standards, Shibboleth may support them if the demand from institutions is sufficient to justify the development expense.

Identity Discovery

Where is the log-in box on a website that supports federated identity? If you have already logged in to your institution's home portal, and you navigate to a website that uses federated identity, no problem: the HTTP session information can be read by the website. But if you have not logged in, how will the website know where to send you to authenticate? The website may have trust relationships with hundreds of IdPs; which one is yours? This is known as the "Where are you from?" problem.

All identity frameworks must deal with this identity discovery problem. Several solutions are being implemented:

• The Kantara Initiative, an industry nonprofit organization formed to facilitate collaboration on digital identity, has a working group dedicated to the Universal Login Experience (ULX) to make the user experience accessible to non-techies.
• Google has put forward the WebFinger standard, based on e-mail addresses as the universal identifier. The usability for this service is high, because people are accustomed to using their e-mail address, but problems arise when the organization responsible for e-mail is not the identity provider. Also, e-mail is not a stable identifier, and in many organizations, e-mail addresses are recycled, which can result in two different people using the same e-mail address over time.
• OpenID 2.0 has a compelling solution for identity discovery that uses Extensible Resource Identifiers, or XRI, and the XDI protocol. By creating a new Internet scale distributed infrastructure for naming, and providing a solution for both persistent and human readable identifiers, XRI offers the most comprehensive solution to identity discovery, but it may take a long time to be widely implemented.

When identity discovery is implemented by websites, not identity providers, each website will choose the solution that works best for their requirements.

Trust Model

RP software used by websites requests information from IdPs about a person's identity. The general idea here is that IdPs electronically authenticate people, and then provide information about them (their attributes) to websites as appropriate. This works because there is a trust relationship between the IdP and RP. The trust model consists of the assumptions that make that trust relationship valid, enabling a website to determine that the information supplied by the IdP is authentic.

Trust models can be cryptographic, for example based on digital signatures of the IdP. A trust model need not be cryptographic, however: deployment of systems on a non-hostile network may obviate the need for any authentication or authorization. Many misunderstandings about the security of federated identity originate from incorrect assumptions about the trust model, such as when each party is using a different trust model.

To further complicate the matter, many websites do not require a secure trust model to use their services. To read your web based e-mail, for example, the best practice might be to use HTTPS; however, the e-mail provider might not stop you from using HTTP instead. Establishing a consistent trust model is one of the things that federations like the InCommon Federation provide to their members.

InCommon uses public key cryptography directly, rather than X.509-based certificate validation, to enable RPs and IdPs to establish trust. Using this trust model, any website that is a member of InCommon can identify a web visitor who has authenticated at an IdP that is a member of InCommon.

Shibboleth supports fine-grained controls over the release of attributes to websites. By default, no attributes of the person would be available to an unknown website, even if it is a member of the federation. Institutions must explicitly configure their IdP to specify what attributes are available to a website. For example, an institution might provide little more than first name and last name for an e-commerce site, but for a payroll processor, an attribute such as employee number might be released.

For higher education institutions, the bottom line is that if the website is not a member of InCommon, you need to understand whether the trust model meets your requirements. If they are not using your trust model, you are accepting their trust model. The goal of many websites is to make connecting easy, not to protect people's privacy.

Trust Framework

The National Institute of Standards and Technology (NIST) Electronic Authentication Guideline¹ indicates that electronic authentication "presents a technical challenge when this process involves the remote authentication of individual people over a network, for the purpose of electronic government and commerce."1 Its a jargony way to say "How do you know the person is really who they say they are?" And even after you authenticate a person, how accurate is the data from the IdP?

A trust assurance framework defines the policies and procedures that enable IdPs and RPs to share data with confidence. How will the website protect the identity data from hackers once the IdP provides it? Does the IdP have proper provisioning in place to ensure inactive students are removed? These practices and policies are the type of issues described by InCommon's guidelines for Silver and Bronze levels of assurance.

Level of assurance is communicated from the IdP to the website. Level of assurance (LoA) is communicated from the website to the IdP. To simplify classification for LoAs, NIST 800-63 defines four levels. Level 1 is the lowest assurance and is supposed to be secure enough to prevent a drunken roommate from reading your e-mail. For high-value financial transactions, Level 3 assurance might be required. Level 4 is for top secret stuff.

InCommon Bronze is a profile for LoA 1, Silver is for LoA 2. The authentication mechanism for LoA 2 is still username and password, but identity proofing is required. This means that real people are correlated to their electronic records, for example by presenting a photo id when completing an I-9 form.²

The Open Identity Initiative, a U.S. government organization, is evaluating trust frameworks for use at federal websites. InCommon Bronze and Silver are under review. In the future, many trust frameworks may exist to address industry-specific requirements. For example, PBS Kids has released a trust framework for the special considerations of handling data about children. The Open Identity Exchange was recently launched to provide a common infrastructure for publishing different assurance frameworks.

Although performing another audit to comply with trust framework obligations has its costs, ultimately identity assurance may increase an institution's return on investment for federated identity by enabling people to access important resources that would otherwise be unavailable.

Conclusion

Kim Cameron, a well-known Microsoft identity guru, writes in the foreword to the newly published Guide to Claims-Based Identity and Access Control³:

"As systems became interconnected and more complicated, we needed ways to identify parties across multiple computers. One way to do this was for the parties that used applications on one computer to authenticate to the applications (and/or operating systems) that ran on the other computers. This mechanism is still widely used — for example, when logging on to a great number of Web sites. However, this approach becomes unmanageable when you have many co-operating systems."

The other downside to authenticating on remote systems is that it decreases your privacy by forcing you to identify yourself. A website might simply need to know that you are a student, over the age of 21, and a U.S. citizen, but there is no way to decouple the attributes from the identity. In the past these seemed like impossible challenges to solve. Today the challenge lies in making people aware of the solution.

Increasingly, federated identity will reduce the time it takes for institutions to utilize new cloud services, reduce the time needed to develop custom software or to integrate custom off-the-shelf software, and minimize the need for account provisioning, one of the most expensive and time-consuming organizational identity management requirements. Federated identity will reduce the number of usernames and passwords a person needs to remember. It will enable people to use their existing digital identity while leveraging the institution's IT systems. It will help protect people's privacy, enabling the institution to vouch for the affiliation of a person without revealing that person's identity. Federated identity will make possible a new set of network applications.

All this sounds great, but where do institutions get started? Federated identity starts with a federated login. After you've launched your IdP service, you can provide specific steps on how to align with the new architecture. Set up an IdP at your institution and join InCommon to take the first steps of a long journey.

1. William E. Burr, Donna F. Dodson, and W. Timothy Polk, "Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology," Special Publication 800-63, Version 1.0.1, NIST (September 1, 2004).
2. Form I-9 is required by the Department of Homeland Security, U.S. Citizenship and Immigration Services, for verification of employment eligibility; all employees working in the United States and hired after November 1986 must fill out the form.
3. Microsoft Corporation, "Guide to Claims-Based Identity and Access Control," 2010.

© 2010 Gluu, Inc. The text of this article is licensed under the Creative Commons Attribution-Share Alike 3.0 license..

Michael Schwartz

Founder/CEO 

Gluu 

Bookmark/Search this page with: