ASP.NET Web Applications   ASP.NET Web Application Security

---

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>

Authentication   <location> Element   Hierarchical Configuration Architecture   Impersonation

Books and more ...

Custom Search

Suggested Reading

Need a break ?