Authentication

12.1 Authentication

Authentication means showing some proof of your identity. When you show a photo ID, like a passport or a driver's license, you are showing some proof that you are who you claim to be. When you type a PIN number into an automatic teller machine, or type a secret password into a computer's dialog box, you also are proving that you are who you claim to be.

Now, none of these schemes are foolproof. Passwords can be guessed or overheard, and ID cards can be stolen or forged. But each piece of supporting evidence helps to build a reasonable trust that you are who you say you are.

12.1.1 HTTP's Challenge/Response Authentication Framework

HTTP provides a native challenge/response framework to make it easy to authenticate users. HTTP's authentication model is sketched in Figure 12-1 .

Figure 12-1. Simplified challenge/response authentication

figs/http_1201.gif

Whenever a web application receives an HTTP request message, instead of acting on the request, the server can respond with an "authentication challenge," challenging the user to demonstrate who she is by providing some secret information.

The user needs to attach the secret credentials (username and password) when she repeats the request. If the credentials don't match, the server can challenge the client again or generate an error. If the credentials do match, the request completes normally.

12.1.2 Authentication Protocols and Headers

HTTP provides an extensible framework for different authentication protocols, through a set of customizable control headers. The format and content of the headers listed in Table 12-1 vary depending on the authentication protocol. The authentication protocol also is specified in the HTTP authentication headers.

HTTP defines two official authentication protocols: basic authentication and digest authentication. In the future, people are free to devise new protocols that use HTTP's challenge/response framework. The rest of this chapter explains basic authentication. See Chapter 13 for details on digest authentication.

Table 12-1. Four phases of authentication

Phase

Headers

Description

Method/Status

Request

 

The first request has no authentication.

GET

Challenge

WWW-Authenticate

The server rejects the request with a 401 status, indicating that the user needs to provide his username and password.

Because the server might have different areas, each with its own password, the server describes the protection area in the WWW-Authenticate header. Also, the authentication algorithm is specified in the WWW-Authenticate header.

401 Unauthorized

Authorization

Authorization

The client retries the request, but this time attaching an Authorization header specifying the authentication algorithm, username, and password.

GET

Success

Authentication- Info

If the authorization credentials are correct, the server returns the document. Some authorization algorithms return some additional information about the authorization session in the optional Authentication-Info header.

200 OK

To make this concrete, let's take a look at Figure 12-2 .

Figure 12-2. Basic authentication example

figs/http_1202.gif

When a server challenges a user, it returns a 401 Unauthorized response and describes how and where to authenticate in the WWW-Authenticate header ( Figure 12-2 b).

When a client authorizes the server to proceed, it resends the request but attaches an encoded password and other authentication parameters in an Authorization header ( Figure 12-2 c).

When an authorized request is completed successfully, the server returns a normal status code (e.g., 200 OK) and, for advanced authentication algorithms, might attach additional information in an Authentication-Info header ( Figure 12-2 d).

12.1.3 Security Realms

Before we discuss the details of basic authentication, we need to explain how HTTP allows servers to associate different access rights to different resources. You might have noticed that the WWW-Authenticate challenge in Figure 12-2 b included a realm directive. Web servers group protected documents into security realms . Each security realm can have different sets of authorized users.

For example, suppose a web server has two security realms established: one for corporate financial information and another for personal family documents (see Figure 12-3 ). Different users will have different access to the realms. The CEO of your company probably should have access to the sales forecast, but you might not give her access to your family vacation photos!

Figure 12-3. Security realms in a web server

figs/http_1203.gif

Here's a hypothetical basic authentication challenge, with a realm specified:

  HTTP/1.0 401 Unauthorized  
  WWW-Authenticate: Basic realm="Corporate Financials"  

A realm should have a descriptive string name , like "Corporate Financials," to help the user understand which username and password to use. It may also be useful to list the server hostname in the realm namefor example, "executive-committee@bigcompany.com".

 



HTTP. The Definitive Guide
HTTP: The Definitive Guide
ISBN: 1565925092
EAN: 2147483647
Year: 2001
Pages: 294

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net