Using Authorization

After you’ve authenticated the user making the request, the next step is to authorize the request. Authorization means deciding whether to permit the user to access the requested resource.

Authorization in ASP.NET takes two major forms: authorization against NTFS Access Control Lists (ACLs) and URL-based authorization.

Using NTFS ACLs for Authorization

ACL-based authorization is useful when you’re using Windows-based authentication in ASP.NET. With ACL-based authorization, you use tools such as the Properties dialog for a file or folder in Windows Explorer to set the list of users or groups that are allowed to access a given resource, and what rights each one has (read, write, execute, and so on). The primary advantage of using ACL- based authorization with Windows-based authentication is that it does not require writing any security-specific code in your ASP.NET application. All security settings can be taken care of administratively.

When a request for a resource (such as an ASP.NET page) comes in, IIS authenticates the request, using whichever method (basic, digest, integrated Windows) has been configured for the application. IIS passes the identity of the logged-in user (or the configured anonymous user account, if anonymous access is enabled) to ASP.NET, which then uses the identity of the user to check the ACL for the requested resource to see if the user has the required permission. If so, ASP.NET fulfills the request.

Configure ACL-based authorization

Configure your ASP.NET application to use Windows authentication and to impersonate the logged-in user by adding the following sections to the application’s Web.config file.
```
<authentication mode="Windows" /> <identity impersonate="true" />
```
Using Windows Explorer, right-click a file or folder in your application’s physical directory that you want to restrict access to, and then select Properties. (You must be logged in as either an administrator or an account with ownership rights on the resource to be configured.)
Click the Security tab and add or remove users or groups as desired. Note that you should remove the Everyone group if it is present. If you want ASP.NET to be able to access a resource when not impersonating, the ASPNET account should be given access to the resource. When you’re finished applying permissions, click OK to close the dialog box.
Browse to the protected resource. You should be prompted to log in using your Windows username and password. If you enter credentials for one of the accounts you configured in Step 3, you should be able to access the resource.

Using URL-Based Authorization

URL-based authorization, which is new in ASP.NET, lets you use the <authorization> element to grant or deny access to resources in your application based on their URL (hence the name). Unlike the <authentication> element, which cannot be used in or applied to a subdirectory of an application, the <authorization> element can be applied to subdirectories and even individual files, either by creating Web.config files in the subdirectories or by using the path attribute of the <location> element to specify the URL for the resource to be protected. URL-based authentication also allows you to specify the HTTP method for which a particular rule applies.

Authorizing Users and Roles

The most basic form of ASP.NET URL-based authorization looks like this:

<configuration>    <system.web>       <authorization>          <allow users="Andrew" />          <deny users="*" />       </authorization>    </system.web> </configuration>

When the <authorization> element shown here is added to the Web.config for an application, it allows Andrew to access resources in the application’s root directory and in any subdirectories that do not have conflicting <authorization> permissions set, as well as denying access to all other users. The users attribute of the <allow> and <deny> elements allows you to specify comma-separated lists of users to be allowed or denied access to the URL being protected. (Note that if no path is specified, ASP.NET will apply the settings to the directory in which the Web.config containing the settings resides, as well as its children.) ASP.NET provides the following two wildcards for allowing and denying access:

* This wildcard lets you allow or deny all users.
? This wildcard lets you allow or deny anonymous users.

You can also specify a comma-separated list of roles (equivalent to NT groups) to allow or deny by adding the roles attribute to an <allow> or <deny> element:

<allow roles="Administrators, Users">

Note that authorization settings for child directories override those of the parent, unless the parent settings are locked down using the optional allowOverride attribute of the <location> element. To prevent the preceding authentication settings from being overridden, you would modify the Web.config file as follows:

<configuration>    <location allowOverride="false">       <system.web>          <authorization>             <allow users="Andrew" />             <deny users="*" />          </authorization>       </system.web>    </location> </configuration>

Note that the <location> element also has a path attribute that allows you to specify the path to which the settings contained between the <location> tags apply. This can be a very convenient way to specify the authorization settings for multiple files or directories in an application from a single Web.config file, allowing the developer or administrator to decide which settings can or cannot be overridden by child Web.config files. This is an especially useful feature in shared server or shared hosting situations. A server administrator can place master permissions in the Machine.config file for the server and use the <location> element to prevent overriding of these permissions.

Allowing or Denying Specific HTTP Methods

In addition to the users attribute, the <allow> and <deny> elements also expose a verbs attribute, which allows you to specify the HTTP verb type to allow or deny for the specified user(s) or role(s). The following example shows how you could prevent all users from making POST requests, while still allowing them other access. Modify your Web.config file as follows:

<configuration>    <location allowOverride="false">       <system.web>          <authorization>             <allow users="Andrew" />             <deny verbs="POST" users="*" />          </authorization>       </system.web>    </location> </configuration>

Limiting the request types to those necessary for a page or pages in your application can be an important way to prevent hackers from compromising your site. If a hacker is unable to make a POST request, it is that much more difficult for him to take advantage of a vulnerability that requires sending data in an HTTP POST request. You can restrict or allow HTTP verb access for a page or set of pages by adding the path attribute to the <location> element, as described in the previous section. The Forms authentication example demonstrates the use of the path attribute of the <location> element.