Deploying an ASP.NET application in a web farm scenario poses a few extra configuration issues. Because the requests for the application can be processed on any machine in the farm, all machine.config files in the various machines must be synchronized on the value of a few critical attributes. There are three information types that must be configured in the same way across the farm: forms authentication cookies, view-state message authentication check (MAC) generation, and session state. The information corresponds to three sections: <machineKey>, <authentication>, and <sessionState>.
The <machineKey> section contains the keys used for encryption (the validationKey attribute) and decryption (the decryptionKey attribute) of the form’s authentication cookie. It goes without saying that all machines in the farm must be able to process an authenticated user, and for this to happen, all of them must be able to decrypt and encrypt authentication cookies in the same way. Hence, the keys must be identical on all machines. The validation attribute must also be replicated if the authentication check is enabled for the view state of one or more pages. The message authentication check (MAC) takes place if the @Page’s EnableViewStateMac attribute is set to True.
The <authentication> section allows you to configure a web site for various types of user authentication, including form-based authentication as well as Passport and IIS-driven authentication. This section has two mutually exclusive subsections—<forms> and <passport>—and the mode attribute to control the authentication mode requested by an application. In case of web farms, the settings for the <forms> section must coincide across the farm to enable the correct treatment of the client cookies.
Finally, all machines in the farm must handle session data in the same way, whether through SQL Server or a remote server. In light of this, all machines must be synchronized on the configuration of the <sessionState> section.
If you have total control over the web server environment, then propagating those settings is not that hard. You just prepare a made-to-measure configuration file and copy it on all machines. In a service provider scenario (ISP), instead, it may happen that some of these settings (or even other settings) are locked down at the machine level by the system administrator. This means that you can’t modify the existing machine.config file and can’t override those settings within an application-specific web.config. In this case, you have only one possible way out—ask (or should I say, beg?) the administrator to create a <location> section for you in all machine.config files. A <location> section is a sort of virtual copy of the machine settings that apply only to a particular web path—just that of your application. A machine.config file can contain as many <location> sections as there are running applications.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
