What is authorization?

Authorization determines whether an identity should be granted access to a specific resources. In ASP.NET, there are two ways to authorize access to given resources:
1)    File authorization – File authorization is performed by the FileAuthorizationModule. It checks the access control list (ACL) of the .aspx  or .asmx handler file to determine whether a user should have access to the file. ADL permission are verified for the user’s windows identity (if windows authentication is enables) or for windows identity of the ASP.NET process.
2)    URL authentication – URL authentication is performed by the UrlAuthorizationModule,  which maps users and roles to URLs in ASP.NET applications. This modules can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles.
Using URL Authorization: -
With URL authorization, we explicitly allow or deny access to a particular directory by user name or role. To do so, we create an authorization section in the configuration file for that directory. To enable URL authorization, we specify a list of users or roles in the allow or deny elements of the authorization section of a configuration file. The permission established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them.

The following shows the syntax for the authorization section: -
<authorization>
    <[allow | deny] users roles verbs/>
</authorization>

The allow or deny element is required. We must specify either users or the roles attribute. Both can be included, but both are not required. The verbs attribute is optional.

The allow or deny elements grant and revoke access, respectively. Each element supports the attributes shown the below:
Users: - Identifies the targeted identities (user accounts) for this element. Anonymous users are identified using a question mark (?). We can specify all authenticated user using as asterisk (*)
Roles: - Identifies a role ( a RolePrincipal object) for the current request that is allowed or denied access to the resources.
Verbs: - Defines the HTTP verbs to which the action applies, such as GET, HEAD, and POST. The default is “*”, which specifies all varbs.

The following example grants to the Kim identity and members of the Admins role, and denies access to the John identity (unless the John identity is included in the Admins role) and to all anonymous users:
<authorization>
<allow users=”Kim”/>
<allow roles=”Admins”/>
<deny users=”John”/>
<deny users=”?”/>
</authorization>
The following authorization section shows how to allow access to the Johan identity and deny access to all other users:
<authorization>
<allow users=”John”/>
<deny users=”*”/>
</authorization>
We can specify multiple entities for both the users and roles attributes by using a comma – separated list, as shown in the following example: -
<allow users=”John, Kim, contoso\Jane”/>
Note that if you specify a domain account name, the name must include both the domain and user name (contoso\Jane).

The following example allows all users to perform an HTTP GET for a resource, but allows only the Kim identity to perform a POST operation:
<authorization>
<allow verbs=”GET” users=”*”/>
<allow verbs=”POST” users=”Kim”/>
<deny vervs=”POST” users=”*”/>
</authorization>

Rules are applied as follows: -
•    Rules contained 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. The default configuration for ASP.NET contains an <allow users=”*”> elements, which authorizes all users. (By default, this rule is applied last). If no other authorization rules match, the requested is allowed. If a match is found and the match is a deny element, the request is returned with the 401 HTTP status code. If an allow element matches, the module allows the request to be processed further.