All .NET applications maintain their information in an XML-based configuration file. Typically, this .config file exists in the same directory as the application’s executable. Web applications, however, refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation. Let’s dissect a sample web.config file and take a look atthe security settings you’ll find there.
Configuration settings and sections
First, look at the overall structure of the configuration file in Listing A. As an XML document, the file must have a root element that encloses all other elements. In this case, the root is, oddly enough, <configuration>. Within the root element are the <system.web> and <appSettings> sections. The <system.web> section identifies the information it encloses as applying to the default Web server, including security information. The <AppSettings> section is where you’ll put any global data for your application. As I mentioned, database connection strings are good candidates for storage, and in my example, I stored the Web site’s DSN-less ODBC connection string there.
Custom error pages
The first item under <system.web> is <customErrors>, which allows you to specify the pages to which your users will be redirected for a variety of errors. In my sample, users are redirected to /errorpages/FileNotFound.html if a 404 error occurs. Any other errors will redirect users to /errorpages/GeneralError.html.
The <authentication> section defines the details of the process the server will use to authenticate users. The three different modes supported are Windows, Forms, and Passport. Let’s look at each mode in detail:
- · Windows authentication authenticates users against Windows system accounts, such as Active Directory. Windows authentication is the most secure form of authentication and is simple for programmers to deal with because the whole process is handled by the operating system. However, each site user needs a system account, so this mode should be limited to intranet applications.
- · Passport authentication uses passports to authenticate users and is the second most secure authentication method. It’s best used on large, live e-commerce Internet applications that can justify the fees for the service commands. It’s the .NET authentication method of choice.
- · Forms authentication is the least secure authentication method because your application must handle authentication itself. However, this is the mode you’ll be most likely to use on your Internet applications because it requires the least administrative effort to maintain.
Referring to Listing A, you can see that the site uses Forms authentication. You can specify a realm name should you want to. Here, I used .ASPXAUTH, which is functionally equivalent to not naming it at all. I just put that element in to remind me that it does indeed have a name.
You can also see that I’ve specified the relative URL for the login page to be /LoginForm.aspx. This URL is where users who haven’t been authenticated will be redirected if they attempt to access a secure page. Anonymous users, assuming you grant them access in your authorization section, won’t be automatically sent to this page.
User authorization and credentials
The <authorization> section holds the settings for explicitly allowing (<allow>) or disallowing (<deny>) access to a user, group of users, or type of user. Allowable values for these settings are: question mark (?) for anonymous users, asterisk (*) for all users, or a comma-separated list of specific user names.
You can specify one or both of the <allow> and <deny> to customize your site’s security. In Listing A, I specified that I’m allowing all users except for anonymous users and four troublemakers who have caused enough trouble to get themselves banned: hacker, cracker, and fasherman. If I were to switch the values for the users’ attributes of the <allow> and <deny> tags, only the anonymous users and the four troublemakers would have access. Anyone else logging in with valid credentials would be locked out.
While you can maintain your user account list by storing the user names in the <credentials> element, I wouldn’t recommend doing so. If you do store the user information in the web.config file, validation can only occur on that particular Web server. In the case of a large-scale Web farm, or load-balanced Web servers, authentication that happened on one machine will also have to occur on any other machines on the farm.
The only way to prevent the user from having to log in at every page is to store that data in a common data store, such as a database. Another reason not to store user credentials in the web.config file is that the server will have to be restarted to reload the new credentials. This should be fixed in future OSs, but for Windows 2000 Servers running IIS5, it’s an ongoing annoyance.
You’ve now seen how to use the elements in the XML file that IIS uses to manage ASP.NET Web applications. This configuration model provides several advantages over what you’ve had access to before. Since IIS monitors the web.config file for changes, any configuration changes instantly become live: No messy server restarts needed.