Implementing ASP.NET Authorization | .NET Security and Cryptography

Authorization is a process in which you determine whether an authenticated user is granted access to a certain page or resource. In ASP.NET there are two primary ways to authorize access to a given resource: file authorization and URL authorization. Let us discuss these two types scrupulously.

File Authorization

File authorization is carried out against the authenticated account provided by IIS. It is executed by the FileAuthorizationModule . It verifies the Access Control List (ACL) ^[16] or permissions on a resource to determine whether the authenticated user has privilege to access the protected resource. The FileAuthorizationModule provides authorization services against the file system ACLs. You can configure the file ACLs for a given file or directory using the Security tab in the Explorer property page. Note that AccessCheck is called only if there is a WindowsIdentity associated with the request., so it's not strictly useful for Forms authentication or Passport, where there tends to just be one Windows account (the anonymous account).

^[16] The ACL is a list that specifies which users or groups have permission to access or modify a particular file; the Windows discretionary access control list (DACL) and system access control list (SACL) are examples of ACLs.

URL Authorization

URL authorization is executed by the URLAuthorizationModule . For URL authorization, the anonymous user is verified against the configuration data. If access is permissible for the requested URL, the request is authorized. By employing the URLAuthorizationModule , you can execute both positive and negative authorization assertions. That is, you can allow or deny access to groups of users or roles. To implement the URL authorization, place the list of users and/or roles in the <allow> or <deny> elements of the <authorization> section of a configuration file.

The general syntax for the <authorization> section is as follows .

 <[element] [users] [roles] [verbs] />

Here, the elements are <allow> and <deny> .

The <allow> element grants the user access to the resource.

The <deny> element revokes the user access to the resource.

The attributes supported by each element are shown in Table 9-15.

Table 9-15. Attributes Supported by the Element (Allow/Deny)

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 the role membership in whatever fashion you like. For example, the default WindowsPrincipal class uses Windows NT groups to determine the 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.

For example, the following code illustrates access being granted to a user named Arun and a role named Administrator. It will deny all other users.

 <configuration>    <system.web>       <authorization>          <allow users = "Arun" />          <allow roles = "Administrator" />          <deny users= "*" />       </authorization>    </system.web> </configuration>

You can specify multiple users or roles by using a comma-separated list:

 <allow users="Arun,Saru,admin\Gnv" />

The domain account (admin\Gnv) has to incorporate both domain and user names .

You can also specify the HTTP method using the Verb attribute, as shown in the following code. For example, this code allows Arun and Saru to use POST action and all others to use only GET action.

 <allow VERB="POST" users="Arun,Saru" /> <deny VERB="POST" users="*" /> <allow VERB="GET" users="*" />

There are two special identities

* ” All users
? ” Unauthenticated (anonymous) users

For example, the following code denies all the unauthenticated users.

 <authorization>     <deny users="?" /> </authorization>

There is also a <location> tag that you can use to specify a particular file or directory.

 <location path="Required path">

The following two authorization sections are different. The first one denies all the users because the first line, <deny users="*" /> , discards the upcoming statements. The second one denies all the users except Arun.

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