Security: Trend Report: Identity Management

• By Doug Gale
• 10/20/05

In this latest update on “Everything You Need to Know About IdM,” columnist Doug Gale lays out the old, the new, and the soon to be must-haves.

INCREASINGLY, A HIGHER EDUCATION institution’s ability to provide services over the network depends on its ability to authenticate, authorize, and provision user access rights in a unified, consistent, straightforward, and effective way. That’s easy to say but devilishly hard to do, and far too complex to cover in a single column!

Still, as we wade into this Byzantine morass of identity management (IdM), it helps to remember that there are four underlying components:

1. Identification (your name or network/system identifier)
2. Authentication (proof you’re you)
3. Authorization (what resources you have permission to access)
4. Directory (information about you and what you are allowed to do)

For now, let’s look at the first two: identification and authentication. Future columns will consider authorization and directory services.

Identification

At the heart of these schemes is how individuals are identified. Over time, single names evolved into first and last names, and more recently, into unique identifiers such as the Social Security Number (SSN). Unhappily, the use of SSNs as identifiers in higher ed creates identity theft and privacy problems, and d'es not easily adjust to our international community. We’re left with the need for a unique identifer or name.

A unique identifier is more than just a long string of numbers (see box, page 18). For example, at Indiana and George Mason (VA) universities, each student is assigned a unique and persistent multidigit identifier (used by the student information system), as well as a unique but easier to remember eight-character network ID and password that can be mapped back to the longer multidigit identifier. Defining a unique identifier is often a politically contentious process.

Authentication

Authentication (AuthN) is used to prove in some fashion that an individual is who he says he is. We can categorize that proof in three ways: something you have (e.g., a key or a birth certificate), something you know (a password), or something you are (e.g., your fingerprints). (See “Security: It’s Not All About Hackers,” Campus Technology, September 2005.)

The higher education environment involves multiple authentications: A student must prove her identity when she first enrolls. This is usually done by the admissions or registrar’s office, and is normally based upon a series of documents (such as high school transcripts) that the student sends the institution. Some institutions are beginning to require arriving students to show a picture ID, although that creates problems in enrolling distance ed students, and may not be any more secure than the traditional process. Jack Suess, vice president for Information Technology at the University of Maryland-Baltimore and co-chair of the Educause/Internet2 Security Task Force, recommends the identity proofing standards developed by the federal government as being both quantitative and flexible. The government’s E-Authentication Web site can be found at www.cio.gov/eauthentication.

Subsequent online authentication uses one or a combination of three general approaches: password strategies, single sign-on strategies, and public key encryption (PKI) strategies. Password authentication is the oldest of the three schemes and must be considered a legacy strategy if used by itself. Single sign-on strategies such as Web initial sign-on (WebISO) and Kerberos are currently popular, while PKI is an emerging technology that may soon become more important.

Password Authentication

Historically, a user is given or selects a semi-secret ID (e.g., jsmith5; a first initial, last name, and a digit) and a secret password, which is then used to log on to a computer or network. The problem of lost or stolen IDs and passwords is commonly addressed by requiring something you have or something you are, in addition to something you know. This two-factor authentication can be as sophisticated as the products discussed in my September 2005 column, or as simple as the ingenious system developed by Entrust (www.entrust.com), in which each user has a small printed card containing a unique 5x10 (5 rows x 10 columns) “bingo card” matrix. When a user logs on, he is challenged by the system to respond with the value in a particular row and column.

Single Sign-On Strategies

Another problem with password authentication is that, in many cases, if the user or the application the user is running wants to access an app on another computer or server on the network, the original host system asserts to the second system that its user is who she says she is. By analogy, this would be like posting a guard at the door to a bank where patrons must have valid passwords to enter, but after they are inside, they can go up to any teller and withdraw money from an account by just saying that it’s theirs. Security by assertion leaves a lot to be desired, but it can be avoided by requiring each user to have a separate password for each application or resource. Of course, this results in users having dozens of passwords, and is so user-hostile that users resort to a printed list of passwords or the use of a common password for everything—thus undermining the security of the whole system. A number of strategies have been developed to allow a user to log on to a network once and reach multiple applications, while preserving the integrity of those applications.

Kerberos. In the case of Kerberos (developed at MIT and used widely in higher ed), the user enters a secret password or PIN to initially sign on to a computer or network. Yet, before he can access another computer or resource on the network, a more complex scheme ensures that the system asking for access in the name of John D'e really is John D'e’s system. Authentication by assertion is not allowed. Using the previous analogy, this would be like having the guard at the bank verify that the patron has a valid password, then escort the patron to the teller’s window where the guard informs the teller that the patron is who she purports to be. While the scheme is no better than the security provided by the initial logon password, it d'es ensure that this level of security is extended throughout the system. An excellent tutorial on Kerberos (the basis for many higher ed authentication schemes) may be found at www.isi.edu/~brian/security/kerberos.html. Find complete technical specs at web.mit.edu/kerberos/www.

Pubcookie. Pubcookie is open source technology developed by the University of Washington, which provides WebISO. When a user points her Web browser at a Pubcookie- enabled app that requires authentication, the Web browser is redirected to the Pubcookie login module on a trusted, secure server. The Pubcookie login server authenticates against an existing enterprise authentication service such as Kerberos, and returns a cookie to the user’s computer. Then the user’s browser is redirected back to the application server. As the user subsequently visits different servers within the enterprise, the cookie will serve as acceptable authentication until the cookie expires. (Go to www.washington.edu/computing/pubcookie and www.pubcookie.org.

Yale Central Authentication Service (CAS). CAS, developed by Yale University (CT) to provide a “pretty good” unified system of access to all Web-based resources, now forms the basis for systems at several universities and can be obtained at www.ja-sig.org.

Federated Authentication. Shibboleth is a national higher education initiative funded by the National Science Foundation (www.nsf.gov) and facilitated by Internet2 (www.internet2.org), to develop an open, standards-based way to authenticate between campuses. The user’s campus authenticates the user and then identifies him to other campusesthrough a “trust fabric” (shibboleth.internet2.edu/index.html). Adoption of Shibboleth has been very slow, largely because so few institutions have a mature campus trust fabric.

PKI Authentication

Finally, the Holy Grail of authentication—PKI. PKI provides a level of authentication akin to having both the guard at the door of the bank and the teller ask for a driver’s license, passport, and fingerprints before any transaction. But PKI hasn’t yet been widely adopted in higher ed largely because the technology is seen as complex and requiring substantial back-room support, either from a knowledgeable staff or an expensive vendor. Educause has developed the Identity Management Services Program (www.educause.edu/imsp) to take advantage of discounted pricing and customized purchasing from vendors such as VeriSign (www.verisign.com). Still, Jeff Schiller, network manager at MIT (one of the few institutions to fully implement PKI), argues that the primary reason for the perceived complexity and expense of PKI is that institutions don’t keep the implementation simple.

Trends and Next Steps

The general trend is from weak to strong authentication. Two-factor authentication for key administrative applications and single-sign-on authentication for just about everything is becoming the norm. Federated authentication and PKI are just around the corner.

So, how d'es your institution get to strong authentication from weak authentication? Some institutions have elected to use an external vendor such as Cybertrust (www.cybertrust.com), Sun Microsystems (www.sun.com), or VeriSign to provide products/systems integration. In addition to cost, one of the challenges to this strategy is the integration of a vendor’s system with the plethora of campus apps (e.g., Blackboard, www.blackboard.com; and Datatel, www.datatel.com.) Other institutions have elected to develop services and software internally, using open software. Most use a mix of both strategies. For example, Indiana University uses the Microsoft Identity Integration Server (www.microsoft.com) as a back end for account generation, and then uses the Yale Central Authentication Service and uPortal (www.uportal.org) open source software on top of Kerberos. Similarly, the University of Miami School of Medicine and George Mason University use Edgewall from Vernier Networks (www.verniernetworks.com) to identify connected machines by their Message Authentication Code (MAC) address, and scan installed software to ensure adherence to institutional policies before connecting the computer to campus applications—in effect, providing two-factor authentication (the user password and the computer itself). The moral: One size d'esn’t fit all.