There are several different authentication systems for Web Services that use the secu- rity authentication mechanisms we’ve described. These systems are listed below. Although some of these systems are focused on authenticating human beings rather
than Web Services applications, they are relevant to this topic because Web Services applications need to be able to handle user information that originates from any of these systems.
Operating system-based authentication. Web Services are usually requested and delivered via HTTP. Therefore, Web Services systems often have Web servers as front ends. Some Web servers perform authentication by using the facilities of the underlying operating system. This is the way that Microsoft’s Internet Infor- mation Server (IIS) performs authentication. IIS offers a variety of methods for authentication. This includes username and password with HTTP basic authen- tication; NT LAN Manager (NTLM) and HTTP digest authentication, both of which are challenge response-based; SSL authentication; and Kerberos authenti- cation. As a result of successfully completing IIS authentication, the user is known to the operating system and the facilities of the operating system can be used for authorization. This is a very powerful capability, but not all system implementers want to establish Windows operating system accounts for Web users.
Web server-based authentication. Web servers generally come with a built-in authentication capability to handle the authentication requirements for HTTP, namely HTTP basic authentication (which is password based) and HTTP digest authentication. Depending on the Web server, the authentication information used can be the same as that used by the operating system, stored in a separate file contained on the same platform as the Web server, or stored in a separate user repository (Lightweight Directory Access Protocol [LDAP]-based). The key point about this type of authentication versus the operating system-based authentication described previously is that a successfully authenticated user will not be known to the operating system. Operating system mechanisms cannot be used to enforce access control. In these cases, the Web server itself enforces access control.
Token-based authentication. With token-based systems, the user must possess a physical token that plays some part in the authentication process, which makes this approach a lot stronger than passwords by themselves. Tokens are fre- quently used for remote access to privileged services because they provide two- factor authentication (physical possession of the token card and knowledge of a PIN). Tokens, however, are more costly and complex to implement than IDs and passwords. Sometimes the token displays a value that must be verified by an authentication server. The token may have a keypad so that a challenge can be input to the token. The token may also have a physical connection to the work- station so that the challenge is automatically entered into the token and the response is automatically sent from the token to the workstation during the authentication protocol. Examples of tokens include CRYPTOCard and RSA SecurID.
Web single sign-on. Authentication is needed just as much for HTTP transac- tions as for other electronic transactions. The difficulty with HTTP is its state- lessness and inability to keep track of a user session. Each request to a Web server is treated as a new request and the user must, theoretically, be authenti- cated again. A solution to this problem is to have the Web browser cache
authentication information and present it with each request to the Web server. This relieves the user from having to reenter it multiple times. However, this compounds the problem of a clear text password traversing the Internet and makes it the problem of a clear text password traversing the Internet with every access to the Web server. Other problems, such as using the same authentication information with different Web servers in the same Web server cluster, still require that the user be authenticated again. In answer to this need, Web SSO systems like Netegrity SiteMinder, Microsoft Passport, Entrust getAccess, and RSA ClearTrust were developed. Web SSO systems maintain a session between HTTP requests to the same server or server cluster. The user logs in once and can access any other Web server in the cluster without logging in again for the duration of the session. If the authentication check passes, the security server creates an encrypted cookie, which contains the username, IP address, browser, time, and expiration time. The Web server returns the cookie to the client browser, which then uses the cookie for subsequent authenticated HTTP requests. The length of a session is governed by the site’s policy. Web SSO sys- tems allow customized and branded login screens. Most Web SSO systems sup- port a variety of authentication mechanisms such as password, RSA SecurID, Windows NT domain login, and public key certificate. They also provide autho- rization services. Since Web servers implement intercepts at key points during the serving of an HTTP request, including authentication, Web SSO systems can easily be integrated with Web servers.
Client/server single sign-on. Just as Web interactions need SSO capability, client/server systems need SSO. In fact, since client-server systems were devel- oped before Web browsers and servers, the need for a client/server SSO was identified earlier. Kerberos is the most common approach for client/server sys- tems, and is used, for example, in Microsoft COM+, described in Chapter 7.
Biometrics. When enterprises need very strong evidence of a user’s identity, they often turn to biometrics. Biometrics includes mechanisms such as retina scan- ners, voice recognition systems, and palm or fingerprint readers. These provide strong authentication, but can be costly and need to be evaluated with respect to false negatives as well as social acceptance. Biometrics are most commonly used at controlled facilities or for highly critical applications with limited users. When used with Web authentication servers, biometrics generally require cus- tom integration.