Authorization in ASP.NET
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
The purpose of authorization is to determine whether an identity should be granted the requested type of access to a given resource. There are two fundamental ways to authorize access to a given resource:
File authorization
File authorization is performed by the FileAuthorizationModule, and is active when you use Windows authentication. It does an access control list (ACL) check of the .aspx or .asmx handler file to determine if a user should have access. Applications can further use impersonation to get resource checks on resources that they are accessing. For more information about impersonation, see Authentication and ASP.NET Impersonation.
URL authorization
URL authorization is performed by the URLAuthorizationModule class, which maps users and roles to pieces of the URL namespace. This module implements both positive and negative authorization assertions. That is, the module can be used to selectively allow or deny access to arbitrary parts of the URL namespace for certain sets, users, or roles.
The URLAuthorizationModule is available for use at any time. You only need to place a list of users and/or roles in the <allow> or <deny> elements of the <authorization> section of a configuration file.
To establish the conditions for access to a particular directory, you must place a configuration file that contains an <authorization> section in that directory. The conditions set for that directory also apply to its subdirectories, unless configuration files in a subdirectory override them. The general syntax for this section is as follows.
<[element] [users] [roles] [verbs]/>
An element is required. Either the users or the roles attribute must be included. Both can be included, but both are not required. The verbs attribute is optional.
The permissible elements are <allow> and <deny>, which grant and revoke access, respectively. Each element supports three attributes, which are defined in the following table.
| Attribute | Description |
|---|---|
roles |
Identifies a targeted role for this element. The associated IPrincipal object for the request determines the role membership. You can attach arbitrary IPrincipal objects to the context for a given request and they can determine role membership in whatever way you like. For example, the default WindowsPrincipal class uses Microsoft Windows NT groups to determine role membership. |
users |
Identifies the targeted identities for this element. |
verbs |
Defines the HTTP verbs to which the action applies, such as GET, HEAD, and POST. |
Anonymous users are also denied.
The following example grants access to Kim and members of the Admins role, while denying it to John and all anonymous users:
<authorization>
<allow users="Kim"/>
<allow roles="Admins"/>
<deny users="John"/>
<deny users="?"/>
</authorization>
Both users and roles can refer to multiple entities by using a comma-separated list, as shown in the following example.
<allow users="John, Kim, contoso\Jane"/>
Notice that the domain account, contoso\Jane, must include both the domain and user name combination.
In addition to identity names, there are two special identities, as shown in the following table.
| Identity | Description |
|---|---|
* |
Refers to all identities |
? |
Refers to the anonymous identity |
To allow John and deny everyone else, one might construct the following configuration section.
<authorization>
<allow users="John"/>
<deny users="*"/>
</authorization>
The following example lets everyone do a GET, but only Kim can use POST.
<authorization>
<allow verb="GET" users="*"/>
<allow verb="POST" users="Kim"/>
<deny verb="POST" users="*"/>
</authorization>
Rules are applied using the following heuristics:
Rules contained in configuration files at lower directory levels take precedence over rules at higher directory levels. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent (nearest in the hierarchy) rules at the head of the list.
Given a set of merged rules for a URL, the system starts at the head of the list and checks rules until the first match is found. Note that the default configuration for ASP.NET contains an <allow users="*"> element, which authorizes all users. If no rules match, the request is allowed unless otherwise denied. If a match is found and the match is a <deny> element, it returns the 401 status code. Applications or sites can easily configure a <deny users="*"> element at the top level of their site or application to prevent this behavior.
If an <allow> matches, the module does nothing and lets the request be processed further.
There is also a <location> tag that you can use to specify a particular file or directory to which settings wrapped by that tag (between <location> and </location> tags) should apply.