There are several levels of username/password security. Some require you to write code; others are more or less automatic. The simplest way to authenticate individuals in an intranet application is to capitalize on Windows' own security. Microsoft calls this type of authentication Integrated Windows authentication.
For example, if all the users have to log in to a Windows domain, then the client workstation already has the client's account information—because the user typed it in to log onto Windows. If you can get the client to provide that account information to the server, where the server is also a member or has trusted access to the client's domain, the server can authenticate the request transparently.
To implement Integrated Windows authentication, you must deny anonymous access. To do that, open the Properties dialog for the CSharpASP application using the Internet Services Manager application. Click the Directory Security tab, and then click the Edit button. You'll see the Authentication Methods dialog shown in Figure 18.1.
AutSnHK JCIOT. Mrtlnnt*
irt tfwd lw wonytrwua -acce*«:
¿fc/ftertscjied «cei i
F.s iclxttg «Jthente-st«>r! -JW rs*w and pa^siHOid «a
■ «nenya&e BK>H4 it fcntiHL i* fcjtfia r. MrHJC+.*iJ Liivj NTF$ KLrtl LCrtfed hftt r BflUt .'Wllrfrtiiairti Ififciiwrd d :<H rti C+iM Itfd?
R elated VmIM
Figure 18.1: IIS Authentication Methods dialog
Uncheck the Anonymous Access item, and check the Integrated Windows Authentication item. Click OK to close all the dialogs and apply your changes. Now, when a user requests any page in the CSharpASP application, the server will attempt to authenticate him transparently. If the server cannot authenticate the client, it will return an access denied header value, and the user will see an Enter Network Password dialog (see Figure 18.2), where he can attempt to provide valid information.
If the user enters invalid information in the Enter Network Password dialog, the server will deny access, the browser will redisplay the dialog, and the user can retry. Every time the user's attempt at access fails, the server returns an access denied error code, and the browser stops parsing the response as soon as it receives the request for authentication. Most servers have a default count for the number of tries they allow before simply returning the access denied message, without the authorization header. On IIS, you can attempt to log in three times before the server denies the attempt. When the user gives up trying to authenticate and presses the Cancel key, the browser parses the remainder of the server's response, which displays the access denied message returned by the server. Figure 18.3 shows the default IIS access denied page.
Note Netscape browsers do not support Integrated Windows security. If you attempt to access a site with Integrated Windows security with a Netscape 6 browser, you won't get any reply. With Netscape 4, you get a Username and Password Required dialog. Note that it's a different dialog than you see when using IE (see Figure 18.4).
The server does not generate the Enter Network Password dialog itself. Each browser has its own built-in dialog. For example, Figure 18.4 shows the dialog generated by Netscape 4.
In previous versions of ASP, you had to implement your own username/password security. Although that's not difficult, it is tedious. Nevertheless, you should know how it works so you will understand what .NET and IIS/IE can do for you to simplify the process.
When you uncheck the Anonymous Access option in IIS for your application, you're telling IIS that it must receive a value in the HTTP logon_user request header variable. Browsers send that value only when challenged by the server to provide authentication information. You can tell IIS to send the challenge by checking any other security option. When you check the Basic Authentication option, IIS challenges the browser for authentication information, and the browser displays a dialog so the user can log on. The username and password sent via Basic Authentication are encoded into base-64, but that's not secure—in fact, it's not true encryption at all. Encoding simply translates characters from one representation to another, while encryption uses various schemes to change the content to make it from mildly to extremely difficult to retrieve the original value without the correct decryption code.
Similarly, when you check the Integrated Windows Authentication option, you're telling IIS to go through a specific series of actions to force IE to provide the user's identity. IE doesn't provide the actual username and password; instead, it provides a hashed token that the server can verify. The entire process is transparent to both the user and the developer, but because Integrated Windows authentication doesn't work with Netscape browsers, it's suitable only for intranet applications.
In the next section, you'll implement authentication using several different methods—including the "old" way using Basic authentication—and explore different ways of accomplishing authentication that are built in to ASP.NET.
Was this article helpful?