How OpenID can lighten the load on user authentication schemes

A research scientist who wants to get alerts on a pertinent topic from Science.gov can get a user name and password from the Energy Department-run site. But when that scientist wants to make an online reservation for some camp space at a national park, he must register all over again, this time with the Interior Department's National Park Service.

From the user's perspective, both accounts are from the same government, so why couldn't the scientist have a single account for both? Or for that matter, why not have one account for all government interactions? In fact, why should that ID be issued by the government at all, especially when commercial organizations, such as Google or Microsoft, are already issuing user identifications en masse?

Earlier this year, when Vivek Kundra became federal chief information officer, he called for greater use of commercial technologies, particularly those emerging in the Web 2.0 field. However, few could have predicted that he would extend such thinking to authentication schemes.

At the O’Reilly/TechWeb Gov 2.0 conference in September in Washington, Kundra announced that the General Services Administration had formed a partnership with the OpenID Foundation that would allow government Web sites to use the lightweight authentication protocol — already used by Google, AOL and others — for their own sites, possibly saving them a lot of headaches in implementing their own authentication systems for the public.

Today, agency Web sites, which number more than 20,000, have moved far beyond static sets of pages.

However, to interact with the public, agencies need to implement a way of providing user accounts for visitors, so the users could keep track of their search results, maintain extended discussions and conduct business. Setting up authentication systems can be a lot of work for the agency, though, and the last thing most Web surfers want is another user name and account to remember.

By partnering with OpenID, Kundra plans to take advantage of work already being done in the commercial and open-source sectors. Most government Web site visitors already have accounts elsewhere, perhaps in various services offered by Microsoft, Yahoo, Google or others. "Why not leverage those platforms for services that are not sensitive in nature?" Kundra asked.

Later at the conference, Judy Spencer, co-chairwoman of the Federal Identity, Credential and Access Management Steering Committee, said a challenge the federal government faces is that it could have 300 million potential users, but what any one might need from the government on any given day may remains a mystery. That makes it difficult for long-term authentication planning.

"Identity is a real problem with us," Spencer said. "For most of the interactions that the government has with citizens, it needs some form of identity assurance." Because people are comfortable with social-networking services, "this is something we think we can leverage." 

In many ways, though, the introduction of OpenID into federal sites is jarring, given how little it was used by agencies before Kundra's announcement. How it works and how it can work for you could require some explanation.

How it works

The easiest way to think about OpenID is as a lightweight sign-on mechanism for consumer-oriented Web sites. Instead of a using a separate set of log-in credentials for Yahoo, for instance, and then using another set for Facebook, the user can deploy a single OpenID user name and password for all these accounts.

"OpenID is fundamentally a way you can use your browser to authenticate to a Web site by using a third-party identity provider," said Drummond Reed, one of the founding board members of the OpenID Foundation, which oversees OpenID.

For the user, the experience can go something like this: When visiting a new site, the person is asked for an OpenID identity. The identity is a Web address of some sort (JoeCitizen.blogspot.com), provided by Google, AOL or some other OpenID provider. After supplying this address to the site, the person is then presented with a log-in page from the provider. After the person logs in to that account on the OpenID provider site, he or she is returned to the original site, which has registered that user for its services. In effect, the OpenID process has verified to the site being visited that the person using that OpenID identity is indeed the account holder.

The first time the person logs on to a service, the OpenID provider gives the user the option of how much data, such as name or e-mail address, to supply the requesting service. The site that is reusing the OpenID identity can assign the visitor a new log-in name. If the person has designated that the OpenID provider always trusts the site being visited, subsequent log-ins to the site using the OpenID will require only the URL — not a user name or password.

Behind the scenes, there are back-and-forth communications between the service requesting verification and the OpenID provider. The service provider constructs a redirect page that takes the user back to the OpenID provider. If the credentials are properly supplied, the OpenID provider sends a "check authentication" message that verifies that the user successfully logged in to his or her account and that the account does indeed belong to the site's visitor.

OpenID makes no assumptions about how the service using OpenID stores the credentials, Reed said. In most cases, information is stored in cookies on the user's computer and the service then treats the OpenID-verified users like any other registered user.

For users, the chief appeal of OpenID is that it could provide a single name and password combination for a wide variety of sites. No longer would a user need to keep a long list of user names and passwords for individual sites. After registering once, OpenID also eliminates that registration process for each individual site, a hassle that often involves switching between Web browser and e-mail client to complete the verification process. And anyone with concerns about entrusting their personal information to any one organization can take heart that, because a wide variety of sites can be OpenID providers, there is no single organization in charge of all IDs, which could be problematic if users start to distrust that provider. Also, users can keep more than one OpenID account.

The list of consumer Web sites that accept OpenID as credentials is growing, even if they lean toward the geeky side: Slashdot, Facebook, Google, Technorati, LiveJournal and Yahoo. The OpenID Foundation says more than 27,000 sites use the protocol, although actual use on the part of the Web populace remains an open question: One Internet service, called WetPaint, dropped support for OpenID, noting that of its 1 million registered users, only 200 logged on with OpenID accounts. Other sites, such as Facebook and Google, hide their OpenID log-on pages.

Government-ready

Installing an OpenID interface to an agency's Web site can be a relatively painless task for administrators. Agencies that run Apache Web server software can install a module from the Apache Foundation that will handle the verification process. Open-source libraries in a variety of languages implement all the message exchange protocols needed, including C#, C++, ColdFusion, Java, Perl, PHP, Python and Ruby. OpenID also can be accessed as a service. JanRain offers a hosted OpenID service, called RPX, which, the company says, is easy to integrate into existing Web sites. If you wish to roll your own, the OpenID Foundation provides all the protocol specifications on its Web site.

Organizations that use open-source content management systems can use OpenID plug-ins, such as Drupal, WordPress and mediaWiki, to simplify setup even further. For instance, setting up OpenID for WordPress is a two-step process, involving uploading and installing a plug-in that supports Extensible Resource Descriptor Sequence operations and another plug-in for OpenID. After the plug-ins are in place, an administrator can simply tweak the discussion settings to accept OpenID credentials as a form of log-on. The plug-ins also let registered users of the WordPress blog use their accounts as OpenID identities for other sites.

Unlike most other authentication schemes that the government is testing, such as the Security Assertion Markup Language, OpenID is designed for open networks. That means not all parties must have agreements beforehand to share credentials. A Web site that uses OpenID credentials assumes only that any OpenID provider is supplying verification that a person wishing to register under a certain account knows the password of that account, the OpenID Foundation’s Reed said. OpenID makes no assumptions about what verification process, if any, the user undertook to get an OpenID account, even from a legitimate provider. After all, you can sign up for an account with Google with no identification whatsoever.

Conversely, however, an OpenID provider could set up a more rigorous process for validating account owners. To ramp up OpenID use in government, GSA created an additional set of criteria for providing IDs for government sites. The GSA Trust Framework Provider Adoption Process specifies what OpenID providers will need to do if they want their credential to be accepted at government sites. It assesses how well providers manage their credentialing by examining what forms of documents they use to verify the applicant's identity, how tamper-proof their systems are, and so on.

To work with the government, OpenID providers must designate that their user accounts meet one of four assurance levels, as defined by the National Instituteof Standards and Technology and an Office of Management and Budget's 2003 memorandum, "E-Authentication Guidance for Federal Agencies" (M-04-04). They range from Level 1, which assumes "little or no confidence in the asserted identity’s validity" to Level 4, which assumes a "very high confidence in the asserted identity’s validity," according to the memorandum. If these assurance levels sound familiar, it’s because they are also used in implementing Homeland Security Presidential Directive 12, the basis for the federal identity cards.

"The [initial] emphasis is on having smooth, easy, lightweight, Level 1 transactions," said Don Thibeau, executive director of the OpenID Foundation. This includes “the kind of Web 2.0 transactions, like blogging, commenting, having a personalized feed of information — all of the things that require you to have an account with the site. What OpenID does is bring the friction down to the minimum."

Only organizations certified by the OpenID Foundation as meeting the criteria will be able to supply OpenID credentials to government Web sites. Not all providers will go through this process, of course, but so far, 10 companies have been verified as adhering to the framework, including AOL, Citi, Equifax, Google, PayPal, Yahoo and VeriSign.

NIH starts small

An early adopter of GSA’s Trust Framework-backed OpenID will be the National Institutes of Health. The agency plans to test the use of OpenID as a component of its single sign-on service, said Dr. Jack Jones, chief information officer of NIH. OpenID could be used to allow people to sign on for a number of Web services, such as customized library searches, access to training resources, registration for conferences and use of medical research wikis.

NIH has been pursuing a type of federated authentication model at least since 2003, Jones said. The idea of cutting back on multiple, redundant user accounts would simplify management for the agency and make life easier for users of NIH’s services.

To work with OpenID, the agency plans to use an authentication infrastructure it had already put in place several years ago, originally to support InCommon, a higher-education identity management federation that allows about 60 biomedical academic institutions to share credentials with one another. "The attractiveness [of InCommon] was that there was a federation out there that we could join and get a lot of people under one single agreement, as opposed to working with each university individually," Jones said.

For NIH, InCommon laid the foundation for using other federated authentication models, such as OpenID. "It taught us a fair amount about what infrastructure to build and how one interacts with a federation and uses remote credentials," Jones said. "OpenID was the next natural step for us." InCommon can be used for academics, while OpenID will be used for public-facing services.

The first test is expected go live at the National Library of Medicine sometime next month. People who search NLM will be able to save their results using their OpenID credentials and come back later to pick up where they left off. If successful, the agency will expand the services to other public-facing Web services, Jones said. At first, only those services with Level 1 assurance will harness the technology, but eventually, applications of greater assurance levels might use the technology, he said, adding that the agency will closely follow GSA's guidance on assurance levels.

That is the plan for the rest of government, too. Spencer said that at first, OpenID could be used for tasks that require some sort of lightweight identification that could help agencies recognize users from session to session, though not one that would yoke an OpenID account to a specific person. Over time, the trust between users and the government could grow through OpenID.

"We won't necessarily know the individual we are doing business with, but we can create a live experience that they can get used to using and be able to have a richer experience in doing online interactions with the federal government," Spencer said. "That can be the starting point where we grow new and more complex services that would require some identity solutions."