Security: Trend Report: Identity Management
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:
- Identification (your name or network/system identifier)
- Authentication (proof you’re you)
- Authorization (what resources you have permission to access)
- 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.
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 (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.
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.
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
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
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
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
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.
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
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
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.
Institutional Identity and Authentication Checklist
How far do you need to go to achieve true IdM and AuthN?
- D'es everyone associated with your institution have a unique identifier with the following characteristics?
- It is unique within the largest population set in which it is used.
- It is not a SSN or other identifier that can be used in identity theft or other ways that violate individual privacy rights.
- It is simple enough for people to remember.
- It is scalable, if your population set increases.
- Has your institution implemented a single sign-on authentication strategy that provides appropriate levels of security for multiple applications?
- D'es your institution have a process for investigating, testing, and adopting emerging authentication technologies such as PKI and federated identity management schemes (e.g., Shibboleth)?