| Let us look at the ASP.NET configuration before moving further, because security is one of the sections in ASP.NET configuration. An ASP.NET configuration file is an XML-based text file that encloses a nested hierarchy of XML tags and subtags with attributes and spells out the configuration settings. Configuration information is stored in XML-based text files, so it is easy to edit and read using any standard text editor or XML parser. In ASP.NET there are two types of XML configuration files: server configuration ( Machine.config ) and application configuration ( Web.config ). ASP.NET configuration files have .config as the file extension. -
The root configuration file, Machine.config , offers the default configuration settings for the entire Web server. Any system that has the .NET Framework installed will have a Machine.config file located in %windir%\Microsoft.NET\Framework\<version>\CONFIG\Machine.config . There are separate Machine.config files for each version of .NET Framework. This facilitates running different versions of ASP.NET Web applications side by side without any difficulty. -
The Web.config file facilitates configuring a specific application or virtual directory. The default Machine.config configuration settings are used if the Web.config is not available. If the Web.config file is present, any settings in Web.config supersede the default settings. The Web.config file provides configuration settings to the directory in which it is situated and to all child directories. The tags, subtags, and attributes present in both the Web.config and Machine.config files are case-sensitive, and the tags must be well- formed XML. The configuration file may be ANSI, UTF-8, or Unicode. The system automatically detects the type of encoding. All the configuration settings are enclosed between <configuration> and </configuration> tags. Facts and Benefits of the ASP.NET Configuration System -
Because the configuration files are XML-based, [6] administrators and developers can easily edit or update configuration settings with the assistance of any standard text editor or XML parser. This makes it easy to modify configuration settings both locally and remotely. [6] Like application settings are stored in the Microsoft IIS metabase in Active Server Pages (ASP), configuration settings are stored in Extensible Markup Language (XML) files in ASP.NET. -
To avoid direct browser access to the configuration files, ASP.NET shields the configuration files by configuring IIS. [7] [7] If anyone directly requests or attempts to access a configuration file, then ASP.NET returns HTTP access error 403 (forbidden). -
The configuration files are extensible; therefore, custom configuration settings can be added. -
New configuration parameters can be included in the configuration file, and configuration section handlers are added to process those parameters. -
If you apply any new configuration settings to Web resources, the ASP.NET automatically senses the changes to configuration files; it recalculates and acclimatizes the new configuration settings accordingly . Thus there is no need to reboot the server for the alterations to take effect. -
Configuration settings can be locked down by means of the <location> tag and the allowOverride attribute. -
In an ASP.NET Web application server, configuration information for the ASP.NET resource is contained in multiple configuration files. Those configuration files can be situated in multiple directories, and all are named Web.config . -
Configuration settings set in the Web.config file apply to its own directory as well as to its associated subdirectories. Configuration Hierarchy If a .aspx receives a request, then ASP.NET calculates the configuration settings hierarchically, as follows . -
Configuration setting in a Web.config file that is stored in a subdirectory overrides the settings of a Web.config file of an application directory. -
Configuration setting in a Web.config file that is stored in an application directory overrides the settings of a Web.config file of Web site settings (root directory). -
Configuration setting in a Web.config file that is stored in a root directory overrides the settings of the Machine.config file. Table 9-1 shows the illustrative configuration file locations for the given URL http://localhost/Myapplication/Mydir/Page.aspx . Table 9-1. Configuration Files Locations | Level | Path | | Configuration settings for the given <version> of the .NET Framework | %windir%\Microsoft.NET \Framework\<version>\ CONFIG\Machine.config | | Web site settings | Inetpub\ wwwroot \Web.config | | Application settings | Inetpub\wwwroot\Myapplication\Web.config | | Subdirectory settings | Inetpub\wwwroot\Myapplication\Mydir\Web.config | A Web.config file at any level is optional; however, a Machine.config file is compulsory. The configuration system first explores the machine configuration file. It then explores the application configuration file. ASP.NET utilizes configuration settings to resources in a hierarchical manner. ASP.NET figures out the configuration settings hierarchically by employing all the configuration files situated in the virtual directory. Additional configuration information provided by the child directories is included with the information inherited from parent directories. The very last configuration settings of the child directories overwrite settings for the same section offered by the parent (i.e., configuration is merged across the hierarchy, with the closest configuration being preferred). Let us consider the URL http://localhost/Myapplication/Dir1/Dir2/Myresource.aspx . Myapplication is the application virtual directory. If a client requests the server for the above URL, ASP.NET computes the configuration settings hierarchically by applying Web.config file settings in the following order as shown in Figure 9-1 Figure 9-1. Hierarchical computation of configuration settings.  The ASP.NET configuration [8] system features an extensible and flexible infrastructure that facilitates adjustment of the configuration settings with minimum impact on Web applications and servers. If you apply any new configuration settings to Web resources, the ASP.NET automatically senses the changes to configuration files, and it recalculates and adapts to the new configuration settings accordingly. That is, ASP.NET listens for file change notifications, restarts the application(s) that are affected, and rereads the changed configuration files in the new application instance. Thus, there is no need to reboot the server for the alterations to take effect. ASP.NET protects certain file types (such as configuration and source code files) from outside access. These file types are located in the Web server's Machine.config file in the framework configuration directory and are assigned to the special HttpForbiddenHandler as follows. [8] The ASP.NET configuration system affects only ASP.NET resources, which are registered to be handled by Aspnet_isapi.dll. For example, ASP, HTML, TXT, GIF, and JPEG files are not secured by the Web.config. To secure these files, you must explicitly map them using the IIS administration tool. <add verb="*" path="*.asax" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.ascx" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.cs" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.csproj" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.vb" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.webinfo" type="System.Web.HttpForbiddenHandler" /> . . . The XML format of both Machine.config and Web.config file is identical. Let's look at the general format of the security section of the Web.config file. There are three key subsections: authentication, authorization, and identity. [View full width] [View full width] <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> //Authentication section: <authentication mode= "[Windows/Forms/Passport/None]"> //Forms Attributes: <forms name="[name]" loginUrl="[Url]" protection="[All, None, Encryption, Validation]"  timeout="[time in minutes]" path="[path]" > //Credentials Attributes: <credentials passwordFormat="[Clear, SHA1, MD5]"> <user name="[UserName]" password="[password]"/> </credentials> </forms> </authentication> //Passport Attributes: <passport redirectUrl="Internal" /> //Authorization section: <authorization> <allow users="*" /> <!-- Allow all users --> <!-- <allow users="[comma separated list of users]" roles="[comma separated list of roles]"/> <deny users="[comma separated list of users]" roles="[comma separated list of roles]"/> --> </authorization> //Identity Attributes section: <identity impersonate="[true/false]" /> </system.web> </configuration> Description All configuration information exists between the <configuration> and </configuration> root XML tags. The <system.web> tag represents all the ASP.NET class settings. AUTHENTICATION -
This section sets the authentication policies of the application. Possible modes are "Windows", "Forms", "Passport" , and "None" , enclosed in quotation marks as shown. -
The default setting is <authentication mode="Windows"> . -
The authentication mode cannot be set at a level below the application root directory. FORMS ATTRIBUTES You can employ Forms-based authentication to configure the name of the cookie to use, the protection type, the URL to use for the logon page, the length of the time the cookie is in effect, and the path to use for the issued cookie. name="[cookie name]": Name of the HTTP cookie used for Forms authentication. The default setting is <forms name=".ASPXAUTH"> . If many applications want to use Forms authentication on the same machine, it is best to use unique names . loginUrl="[url]": The custom login page, where the user is redirected if the user has not already been authenticated. The default setting is <forms loginUrl="default.aspx"> . Redirection may be on the same computer or on a remote one. If it is on a remote computer, both computers should use the same value for the decryptionkey attribute. protection="[AllNoneEncryptionValidation]": Protection mode (i.e., the type of encryption and validation used for the cookie) for data in a cookie. The default setting is <forms protection="All"> , which does validation and encryption. Table 9-2 shows the options for the protection attribute. Table 9-2. Options for the Protection Attribute | Item | Details | | All | Specifies that the cookie can be protected by means of both data validation and encryption. This option uses the configured data validation algorithm (based on the <machineKey> element). When Triple DES is accessible and the key is long enough (48 bytes), it can be used for encryption. This is the default and recommended value. | | None | This setting offers better performance than any other method of doing personalization with the .NET Framework. This is used in sites where a cookie is used only for personalization. While using this method, you must be careful because both encryption and validation are inactive. | | Encryption | The cookie may be encrypted by means of Triple DES or DES, discussed in earlier chapters, but in this method the cookie is not validated . This type of cookie might be subject to chosen plaintext attacks. | | Validation | The encryption is not carried out on the cookie. It only validates the cookie data. | timeout="[minutes]": Duration of time in integer minutes for a cookie to be valid (reset on each request). The default setting is <forms timeout="30"> . The timeout attribute is a sliding value, expiring n minutes from the time the last request was received. path="/": Sets the path to store the cookie on the user's machine. The default value is "/" . The default value is recommended to avoid difficulties with mismatched case in paths, since browsers are strictly case-sensitive and a path-case mismatch could prevent the cookie from being sent with the request. CREDENTIALS ATTRIBUTES The <credentials> element allows you to store your users list in the Web.config file. You can also implement a custom password scheme to use an external source, such as a database, to control validation. -
passwordFormat="[ClearSHA1MD5]": Format of user password value stored in <user> (Table 9-3). -
The <credentials> subtag supports one attribute and one subtag (Table 9-4). -
The <user> subtag supports two attributes (Table 9-5). -
The default setting is <credentials passwordFormat="SHA1"> . Table 9-3. Options for the Password Format Attribute | Attribute | Option | Description | | Password format | | Specifies the encryption format for storing passwords. | | | Clear | Specifies that passwords are not encrypted. | | | MD5 | Specifies that passwords are encrypted using the MD5 hash algorithm. | | | SHA1 | Specifies that passwords are encrypted using the SHA-1 hash algorithm. | Table 9-4. Subtag of the <credentials> Subtag | Subtag | Description | | <user> | Allows definition of user name and password credentials within the configuration file. | Table 9-5. Two Attributes of the <user> Subtag | Attribute | Description | | Name | The logon user name | | Password | The user's password | PASSPORT ATTRIBUTES The passport attribute redirectUrl=["url"] specifies the page to redirect to, whether the page requires authentication, and if the user has not signed on with passport. AUTHORIZATION This section sets the authorization policies of the application. You can allow or deny access to the application resources by user or role. Wildcards can be used as follows: " * " means everyone; " ? " means anonymous (unauthenticated) users. IDENTITY ATTRIBUTES The identity attribute impersonate="[truefalse]" impersonates a request entity (e.g., Windows user). | 