Authorization is the process of determining if an authenticated user has access to the resource(s) they requested. The authorization modules are called if the request has not been rejected. The authorization modules are also defined in the httpModules element in the machine-level Web.config file as shown here:

<httpModules>
<add name="UrlAuthorization"
type="System.Web.Security.UrlAuthorizationModule" />
<add name="FileAuthorization"
type="System.Web.Security.FileAuthorizationModule" />
<add name="AnonymousIdentification"
type="System.Web.Security.AnonymousIdentificationModule" />
</httpModules>

There are two types of Authorization:

1. File authorization
2. URL authorization

File Authorization:
File authorization is performed by the FileAuthorizationModule, and is active when we use Windows authentication. It does an access control list (ACL) check of the .aspx or .asmxIdentity object in the HttpContext.User.Identity property is an instance of the WindowsIdentity class. If the Identity object is not an instance of the WindowsIdentityFileAuthorizationModule class stops processing.

If an instance of the WindowsIdentity class is present, the FileAuthorizationModule class calls the AccessCheck Win32 function to determine whether the authenticated client is authorized to access the requested file. If the file's security descriptor contains at least a Read Access Control Entry (ACE) in its Discretionary Access Control List (DACL), the request is allowed to proceed. Otherwise, the FileAuthorizationModule class calls the HttpApplication.CompleteRequest method and returns a 401 status code to the client.

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. We 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.
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. It checks whether the class, then the

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:

Anonymous users are also denied.

Example:

<authorization>
<allow users="Visualbuilder"/>
<allow roles="Admins"/>
<deny users="www"/>
<deny users="?"/>
</authorization>

The above example grants access to “Visualbuilder” and members of the Admins role, while denying it to “www” and “all anonymous users”.

In addition to identity names, there are two special identities, as shown in the following:

To allow Visualbuilder and deny everyone else, one might construct the following configuration section.

<authorization>
<allow users=" Visualbuilder "/>
<deny users="*"/>
</authorization>

The following example lets everyone do a GET, but only Visualbuilder can use POST.

<authorization>
<allow verb="GET" users="*"/>
<allow verb="POST" users=" Visualbuilder "/>
<deny verb="POST" users="*"/>
</authorization>