WWW Authentication

Up to now, your IIS has been set to allow anonymous logons, which means that anyone in the world can access your server without supplying a user name or password. All users are logged on as IUSR_MYMACHINENAME and can access any files for which that user name has permissions.

As stated in Chapter 34, you should be using NTFS on your server for maximum security.

Basic Authentication

The simplest way to limit server access is to enable basic authentication. Then, if a client makes an anonymous request, the server sends back the response

HTTP/1.0 401 Unauthorized

together with a response header like this:

WWW-Authenticate: Basic realm="xxxx"

The client prompts the user for a user name and password, and then it resends the request with a request header something like this:

Authorization: Basic 2rc234ldfd8kdr

The string that follows Basic is a pseudoencrypted version of the user name and password, which the server decodes and uses to impersonate the client.

The trouble with basic authentication is that intruders can pick up the user name and password and use it to gain access to your server. IIS and most browsers support basic authentication, but it's not very effective.

Windows NT Challenge/Response Authentication

Windows NT challenge/response authentication is often used for intranets running on Microsoft networks, but you can use it on the Internet as well. IIS supports it (see Figure 35-2), but not all browsers do.

If the server has challenge/response activated, a client making an ordinary request gets this response header:

WWW-Authenticate: NTLM Authorization: NTLM T1RMTVNTUAABAAAAA5IAA ...

The string after NTLM is the well-encoded user name—the password is never sent over the network. The server issues a challenge, with a response header like this:

WWW-Authenticate: NTLM RPTUFJTgAAAAAA ...

The client, which knows the password, does some math on the challenge code and the password and then sends back a response in a request header like this:

Authorization: NTLM AgACAAgAAAAAAAAAA ...

The server, which has looked up the client's password from the user name, runs the same math on the password and challenge code. It then compares the client's response code against its own result. If the client's and the server's results match, the server honors the client's request by impersonating the client's user name and sending the requested data.

When the client resends the request, the challenge/response dialog is performed over a single-socket connection with keep-alive capability as specified in the Connection request header.

WinInet fully supports Windows NT challenge/response authentication. Thus, Internet Explorer 4.0 and the EX34A WinInet clients support it. If the client computer is logged on to a Windows NT domain, the user name and password are passed through. If the client is on the Internet, WinInet prompts for the user name and password. If you're writing WinInet code, you must use the INTERNET_FLAG_KEEP_CONNECTION flag in all CHttpConnection::OpenRequest and CInternetSession::OpenURL calls, as EX34A illustrates.

The Secure Sockets Layer

Windows NT challenge/response authentication controls only who logs on to a server. Anyone snooping on the Net can read the contents of the TCP/IP segments. The secure sockets layer (SSL) goes one step further and encodes the actual requests and responses (with a performance hit, of course). Both IIS and WinInet support SSL. (The secure sockets layer is described in the IIS documentation.)