Authorization determines whether an identity should be granted the
requested type of access to a given resource.
ASP.NET implements authorization through authorization providers, the
modules that contain the code to authorize access to a given resource.
ASP.NET includes the following authorization modules.
| ASP.NET Authentication Provider |
Description |
| File authorization |
File authorization is performed by the FileAuthorizationModule,
and is active when the application is configured to use Windows
authentication. It checks the access control list ( ACL ) of the file to
determine whether a user should have access to the file. ACL
permissions are verified for the Windows identity or, if impersonation
is enabled, for the Windows identity of the ASP.NET process. For more
information, see ASP.NET
Impersonation. |
| URL authorization |
URL authorization is performed by the URLAuthorizationModule,
which maps users and roles to URLs in ASP.NET applications. This module
can be used to selectively allow or deny access to arbitrary parts of
an application ( typically directories ) for specific users or roles. |
To enable URL authorization for a given directory ( including the
application root directory ), you need to set up a configuration file
that contains an authorization
section for that directory. The general syntax for the authorization
section is as follows:
<authorization>
< [ allow | deny ] [ users ] [ roles ] [ verbs ] />
</authorization>
The allow or deny element is required, and either the users
or the roles attribute must be specified. Both can be included,
but both are not required. The verbs attribute is optional.
The allow and deny elements 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. For more
information, see ASP.NET
Roles. |
| users |
Identifies the targeted identity names ( user accounts ) for this
element. For more information, see ASP.NET
Membership. |
| verbs |
Defines the HTTP verbs to which the action applies, such as GET,
HEAD, or POST. The default is "*", which specifies all
verbs. |
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 grants access to Mary and members
of the Admins role, while denying access to John
( unless John is a member of the Admins role )
and to all anonymous users.
<authorization>
<allow users = "Mary" />
<allow roles = "Admins" />
<deny users = "John" />
<deny users = "?" />
</authorization>
Both users and roles can refer to multiple entities by using a
comma-separated list such as in the following:
<allow users = "John, Mary, redmond\bar" />
Notice that the domain account [ redmond\bar ] must
include both the domain and user name.
The following example lets everyone do a GET, but only Mary
can use POST:
<authorization>
<allow verb = "GET" users = "*" />
<allow verb = "POST" users = "Mary" />
<deny verb = "POST" users = "*" />
</authorization>
Rules are applied using the following heuristics:
- Rules defined in application-level configuration files take
precedence over inherited rules. The system determines which rule takes
precedence by constructing a merged list of all rules for a URL, with
the most recent rules ( those nearest in the hierarchy ) at the head of
the list.
- Given a set of merged rules for an application, ASP.NET starts at
the head of the list and checks rules until the first match is found.
- If a match is found and the match is an <allow>
element, the module grants access to the request.
- If a match is found and the match is a <deny>
element, the request is returned with a 401 HTTP status code.
- If no rules match, the request is allowed unless
otherwise denied.
Notice in the last situation, the request is allowed access even if
no rules were matched. This happens so because the default configuration
for ASP.NET defines an <allow users = "*"> element, which
authorizes all users. By default, this rule is applied last.
To prevent this behavior, define a <deny users = "*">
element at the application level.
Like all other configuration settings, the access permissions
established for a directory also apply to all of its subdirectories,
unless explicitly overriden in a child configuration file.
Instead of defining access permissions in separate directory
configuration files, you can also define one or more location
elements in a root configuration file to specify the particular files
or directories to which authorization settings defined in that location
element should apply.
The following code example demonstrates how to allow an anonymous
user to gain access to the Logon.aspx page.
<configuration>
<location path = "Logon.aspx">
<system.web>
<authorization>
<allow users = "?" />
</authorization>
</system.web>
</location>
</configuration>