Authentication >> The Power of Who

• By Matt Villano
• 12/30/04

As colleges and universities continue to sharpen identity management applications, next-generation technologies are closer than ever before.

In the ever-changing environment of academic technology, it’s one thing to secure your enterprise network, but entirely another to provision it to control access based on a user’s identity. With this in mind, imagine a network that grants access to certain systems based upon who a particular user is; a network that requires users to sign in only once, and remembers who they are for the remainder of their session. Think of a network that d'esn’t require passwords at all; a network that ties all access to a USB key or the biometric codes of a human fingerprint. Then, envision a network combining all of these characteristics; so sophisticated it operates seamlessly with networks at other schools, and allows users access to similar systems elsewhere in the academic world.

Is the Future Here Yet?

Truth is, a network that manages all of these functions may not be so far off. Welcome to the world of identity management (IdM), where just about anything is possible. Once relegated to the far reaches of network management, IdM has exploded to the forefront of the academic IT consciousness. In fact, as security has become a bigger issue for campuses of every size, so too has identity. For two years in a row now, the Educause Current Issues Survey (irmppc.calpoly.edu/2003/Educause-TopIT-Issues2004.pdf) has listed security and IdM among the top five strategic issues facing higher education. Gartner (www.gartner.com) analysts estimate that growth in this technology sector will reach just over $500 million by 2007, at an annual growth rate of 15 percent.

“Managing identity is, hands down, the biggest part of our security efforts today,” says Ariel Silverstone, chief information security officer at Temple University in Philadelphia. “Just about everything we do revolves around this [technology].”

Many approaches. Indeed, since the turn of the millennium, institutions have taken various approaches to solving their IdM needs, including homegrown systems; large-scale, single-solution partnerships with leading vendors; and piecemeal solutions designed to address specific pain points such as passwords. As colleges and universities continue to sharpen their identity management approaches, however, technologies such as single sign-on logins, once perceived to be “next-generation,” suddenly seem closer than ever before. What’s more, at the behest of the Internet2 consortium (www.internet2.edu), academic technologists also are making huge strides to develop an IdM system that cuts across institutional lines.

The cost issue. Granted, these efforts are not without their challenges, the largest of which is cost. Any sort of identity management effort beyond basic authentication costs money, and while some of the biggest schools spend millions on IdM every year, many of the smaller schools don’t have the resources to grow a basic authentication solution into one sophisticated enough to provide legitimate security. Still, as vendors and technology leaders on the academic side pull together to develop IdM solutions that can work for everybody, one thing is certain: The future of identity management in academia is here now.

The Trailblazers

Rating at Temple. If anybody knows about managing identities, it’s Temple’s Silverstone. After years of relying on disparate mainframes for general computing, Temple officials switched to client/ server architecture in 1999 and hired the former KPMG consultant to come in and create a unified security plan. Central to Silverstone’s blueprint was a schematic that he calls “risk profiling”—a detailed rundown of the sensitivity levels of all of the different systems on campus. Silverstone rated each of these systems for authentication, and drew a direct correlation between the most sensitive systems and the number of authentication factors that should be necessary to access them. When he was finished, the most sensitive systems, such as finance, medical records, and student information, required three factors to gain access: passwords and USB tokens. Thus, Temple’s identity management strategy was born.

Today, all of the school’s identity management is tied together under one solution: Sun Java from Sun Microsystems (www.sun.com). When users register on the system, they are provisioned for systems of every sensitivity level. If a user is expected to perform nothing on the campus network but e-mail and other basic functions, all that he needs to access the system is his password. If a user is expected to access more sensitive systems, he is given additional authenticating factors, such as the USB token or access to a biometric reader. Under this approach, a user’s identity never needs to be re-provisioned; the more access a user needs, however, the more he must prove that he is who he says he is.

“If we don’t know which users are allowed to access the most sensitive information, we don’t really have a way to secure anything,” explains Silverstone, who says the IT department spent $2.5 million on identity management last year alone. “On the flip side, if we know what the data in a system is, and we know what level of risk it poses if compromised, it’s important to grade things accordingly.”

Three steps for all. At Duke University (NC), technologists take an even more conservative approach, building their entire network around a three-step process to establish and confirm identity. There, Michael Gettes, senior technology architect and strategist, started with Kerberos ( web.mit.edu/kerberos/www), the popular network authentication protocol developed at MIT that was designed to provide authentication for client/server applications by using public-key cryptography. Kerberos uses cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. At Duke, after both client and server have used this protocol to prove their identities, they also can encrypt all of their communications to assure privacy and data integrity as they go about their business.

With this as the basis for the school’s IdM system, the university then invested in eDirectory and the Nsure Identity Manager from Linux vendor Novell (www.novell.com), to provision the user database. On top of that, the school built proprietary business logic designed to incorporate additional identifying characteristics and attributes for final authorization. Now, whenever a user tries to log on to even the most basic of systems, she g'es through Kerberos authentication, provisioning from Novell, and another level of authorization—a process that establishes an identity, checks it against a database to confirm a set of access priorities, and culminates with approval or denial. For access to some of the most sensitive systems, the best-of-breed system may, going forward, require additional authentication; secondary factors such as Smartcards and USB tokens.

“For us, the fact that you can have an identity that can be authenticated is independent of what you can access, and the process of granting you authorization to access it,” Gettes says. “That’s why Duke approached the process in three separate steps.”

And the Password Is...

While large schools such as Duke and Temple have spent millions of dollars and thousands of hours developing multifaceted IdM systems, other schools have focused their dollars and energy on a common point of pain: passwords. For instance, at the University of Washington in Seattle, Senior Technology Architect Bob Morgan wrote a single sign-on system that enables students to log in through a Web portal and access up to 400 campus applications without logging in again. The system, dubbed “Pubcookie,” is an open source program that automatically delivers necessary information about a user’s identity when an application requests it, provided that user has authenticated previously. Because Morgan developed it in house, the system cost virtually nothing.

Fewer passwords. The same can’t be said for a new system recently implemented at San Francisco State University (SFSU)—one that also revolves around minimizing passwords through the process of single sign-on. There, technologists in the school’s housing and residential services department called upon Digital Persona (www.digitalpersona.com) to develop a biometric authentication that could integrate with the school’s Microsoft (www.microsoft.com) Active Directory and help to control access to particular systems. Today, the department uses the technology on nearly 50 administrative support computers at $150 per seat, and limits access to only those who have to interface with the machines every single day.

Andy Stockton, technology officer for Housing and Residential services, says the technology behind the SFSU implementation is simple: single sign-on password technology is subtly tied to certain characteristics of every user’s unique fingerprint. Last year, Digital Persona provided the school with U.are.U optical fingerprint scanners that plug into USB ports and capture a 500 dpi image of a user’s fingerprint, encrypt it, send it to the Digital Persona IDentity Engine server, and compare the data with fingerprint information already stored in a database. If the system determines a match, it grants the user access to any variety of systems based upon parameters in the user’s file. If the system fails to find a pairing, it denies access and offers the user only the most basic of services, which generally consists of nothing but simple Web browsing.

“Essentially, this system allows us to take users and give them single-sign-on access without telling them their ‘passwords,’” says Stockton. “If [those codes] are tied to their fingerprints and they don’t know what they are, users can’t share them or lose them, nor can they forget them and request a reset.”

Log on once. San Francisco State isn’t the only school spending money on tackling passwords. At Vancouver Community College (Canada), technologists have turned to Novell to deliver automated e-mail services, and students are now able to access personal e-mail accounts through an entirely automated process. The system, provisioned through Novell solutions similar to the ones used at Duke, enables students to log on once when they first sign in for a user session, then access e-mail repeatedly for roughly three hours without entering user names or passwords again. According to Stephen Forrest, manager of Network Services, the school plans to add other applications to the identity system later this year, such as library, research materials, class calendars and schedules.

Synchronize, synchronize. Then there’s the University of Alaska, which recently purchased P-Synch (a similar off-the-shelf solution) from M-Tech Information Technology (www.mtechit.com). For about $10 a seat, the solution enables student, faculty, and staff users to synchronize passwords across different applications to allow access to as many as five different apps, and can reset lost or forgotten passwords through a self-service reset portal. Peter Rock, the school’s director of Information Technology Services Infrastructure, adds that P-Synch also benefits help desk technicians: As these employees make monthly and weekly sweeps through the network, they can use the system to identify any unused accounts and clean up corporate directories.

The End Goal

Federated authentication. However divergent, each of these technologies works to authenticate users on a particular campus. Now, academic IT thought leaders are looking toward technologies that will allow a user to become authenticated at one campus, to securely access protected resources at another—technologies that would serve to federate identity forever. This type of federated authentication has become the Holy Grail of identity management, and has been championed by members of the Internet2 organization as the project of the future. Dubbed “Shibboleth” (shibboleth.internet2.edu) for the Biblical story of Shibboleth used as a password, it leverages campus middleware infrastructures such as Kerberos and directory services, to support inter-institutional authorization decisions.

About Shibboleth. The Shibboleth project was formed in the late 1990s by Internet2 to develop an open-source, standards-based architecture providing trusted, inter-institutional access to Web resources. It consists of software resident on both the browser user’s campus (the Identity Provider component, which authenticates the user and then provides trusted assertions about the person) and the resource provider site (the Service Provider component, which obtains and validates the assertions and makes an access-control decision). When an unidentified user attempts to access services (see box, left), Shibboleth initiates a handshake between the Service and Identity Providers. During it, the Identity Provider creates attribute assertions describing the browser user to the Service Provider. Ann West, speaking for the NSF Middleware Initiative Project (www.nmi-edit.org), an Educause/Internet2 collaboration, says the business case for such a system is clear.

“If you want to share online resources, you shouldn’t need to keep track of 100,000 IDs,” says West. “The whole idea behind federated IdM is to set up a relationship among campuses and their resource providers, and have a user’s home institution—his identity provider—vouch for that user and release his identity information appropriately.”

West explains that Shibboleth also provides for institutionally and individually defined privacy policies to govern which attributes are to be shared with which service providers. These privacy policies serve as a failsafe to guard not only Shibboleth campuses against inappropriate data releases, but also to protect individuals against worst-case scenarios such as identity theft. They are explained in the SunGard/SCT white paper, “Identity and Access Systems for Higher Education,” at www.sungardsct.com/Education/solutions/s_identity.html.

Barriers—and opportunities. As the Shibboleth system evolves, perhaps the only stumbling blocks to participation are cost and time. To implement it, schools must have in place an IdM framework, be able to authenticate their users, and have an attribute repository (typically, an LDAP directory)—a level of sophistication that many smaller schools lack. Some larger schools are trying to address this issue by writing freeware programs that other, more resource-strapped institutions can adopt. On the vendor side, companies like Sun have redoubled their efforts to offer federated IdM solutions any organization can afford. In the short term, this strategy may not be the wisest for vendors in the competitive high-tech space, because it would eliminate market sectors for them, and cannibalize their own sales. Down the road, however, John Barco, director of Strategic Marketing at Sun, says investing in IdM is a gamble that could pay huge dividends.

“There are still some issues to work out, but when you think about it, that vision of federated identity management is pretty amazing,” Barco says, noting that even in the corporate world, federated IdM is beginning to take hold. “Today, many schools are only dreaming of this technology, but realistically, an identity management program that cuts across hundreds of institutions is not that far away.”