Enterprise User Identification and Authentication Challenges
During the time of centralized computing when users had to use terminals connected by means of serial links to a mainframe or central computer, authentication was centralized and there was only one place where it could be performed - the only intelligent component was the central host. Later on, when minicomputers were connected to the first networks and started communicating with one another using protocols such as TCP/IP, the authentication model started to change and became relatively decentralized. Users now needed an account on every host to which they wanted to connect.
Apart from interactive sessions, however, because of the small number of networked hosts and therefore authentication databases, accessing resources that resided on one host from another host was a matter of a simple model of trust where authentication was not really vital. The model of trust at that time was based on the UNIX r* commands (such as rsh and rlogin) that provide for an authorization file with a list of remote users who are allowed equivalent access to the one a local user has on a particular host. Authentication was not really involved; it was simple identification, wherein the user ID of the requesting user, as well as the name or IP address of the requesting host, could be deduced by the r* request.
In the early 1980s, the IBM Personal Computer and Apple Macintosh started the personal computer (PC) revolution, and now every user had a microcomputer on his desk. UNIX workstations also became popular and now even UNIX users could have their own dedicated host on their desks. Personal computers meant (somewhat) decentralized computing; and in order to be able to share resources in a decentralized world, networking advances were required by the industry. Among the main requirements from the network infrastructure was the ability to authenticate in a network of micro-hosts.
As a result, many authentication systems were developed, and this book presents many of commercial and industry systems that have survived for the past 20 years. However different these systems might be, they fall into two main categories: (1) centralized and (2) decentralized authentication systems.
The decentralized authentication approach (Figure 1) allows each network host to maintain its own user authentication database and policies. UNIX hosts have their own and are independent from other hosts' /etc/passwd file and may potentially use PAM but will still maintain an independent database of users. Windows hosts maintain their own local security accounts manager (SAM) database and authenticate users against this database.
Figure 1 Decentralized authentication workgroup model.
The centralized authentication approach (Figure 2) requires hosts to trust and follow the policies defined by a central authentication authority. This may be just one host, or it may be a set of hosts that form a logical authentication authority. The authentication authority has an authentication database that can be used by all the hosts participating in the centralized authentication system.
Figure 2 Centralized authentication domain/realm model.
An advantage of the decentralized approach is that it allows for user authentication autonomy. In systems that require a very high level of security, designated hosts may be hardened and configured in a secure way to allow access to highly sensitive information assets. Such high security hosts or workstations are not likely to trust other parts of an information system which have a lower level of security. Another advantage of the decentralized approach is that there is no dedicated hardware required for centralized authentication authority servers, so this makes this model appropriate for home networking and small organizations of a couple of networked computers.
The disadvantage of the decentralized approach is that it requires authentication every time a user from one host needs to access resources on another host. Every user needs to have an account and associated credentials, such as a password, on every host on which there are resources that this user may need to access. A separate account should be created on every host.
Unfortunately, this does not scale well for more than a few computers. In a network of ten computers where each user has his own computer, and administers his own authentication database, for a complete trust between all the users so that every user can access resources on every other computer, 10 x 10 = 100 accounts will be required: every user has an account on his own host, and a separate local account on every of the other nine hosts. Every time a user needs to access a resource on a remote host, he might potentially need to use a different username assigned by the administrator of the remote host. Potentially, he may also need a different password. If the user wants to maintain the same password on all hosts, then every time the password is changed on one host, it should also be changed on all other hosts. The whole maintenance of this otherwise simple model takes a lot of user and administrative time and effort.
A disadvantage of the centralized approach is that if a user account is compromised, the attacker has access to any resource to which the user account has access. For some information systems, this model may be unacceptable.
An example of decentralized authentication is the Windows Workgroup authentication model (Figure 1). In this model, each computer stores authentication information locally in a portion of the machine registry called the Security Accounts Manager (SAM). Each computer in a workgroup defines its own local authentication policies and user accounts. To log on interactively from such a workstation or to access resources on this workstation over the network, users must have a user account defined locally in the SAM for this workstation.
Examples of centralized authentication are Windows NT and Active Directory domains (see Figure 2). In both cases, information is stored centrally in a user database, which is made available by set of authentication servers known as domain controllers. In the case of Windows NT, authentication information resides in the SAM. For Windows 2000 and later, user authentication information is a subset of the information stored in Active Directory.
Centralized authentication is a generic term for Single Sign-On (SSO). In today's information systems, organizations invest money and effort to make sure that users are authenticated only once (sign-on only once) but then are able to access resources anywhere on the network. SSO implies unified authentication for access to both the infrastructure using port access control technologies, or remote access, such as dial-up or VPN, as well as services: e-mail, file services, Web portals, management information systems, etc. Unfortunately, at the time of this writing, true SSO is rarely possible.
In an ideal world, all the applications and services in an organization will use a single centralized authentication database to provide for user authentication. Unfortunately, services at the infrastructure layer, as well as applications and services at upper layers, have their own authentication methods and databases.
One of the approaches to SSO is identity management. Organizations - especially those with legacy applications and information systems - may have a multitude of directory services with information about users. For example, many organizations have a human resources database, a phone directory, and legacy plaintext files in the file system for user authentication. Users in the phone directory may be listed by their full names, and plaintext authentication files may use user IDs. The human resources database may use employee IDs as the primary way of identifying users. Identity management solutions typically provide for directory replication or synchronization so that system designers can create relationships and effectively use information from all the directories. This is often achieved using a metadirectory: a centralized, consolidated directory with information from all potential sources. Once data has been consolidated in the metadirectory, it can then be replicated to each and every directory, and updated as necessary or on a regular basis.