Authorization is the process of determining whether the user identified by the authentication process is allowed to access the resource that they're requesting or whether to take the action that they're attempting to take (such as updating data in a database). While authentication asks the question "Who are you?", authorization asks the question "Are you allowed to do that?" The answer to that question determines whether the user's action is allowed.
Authorization in ASP.NET takes three forms, which are all discussed in this section: ACL-based authorization, URL authorization, and programmatic authorization.
Access Control Lists (ACLs) are used in Windows NT, Windows 2000, Windows XP, and Windows Server 2003 to control access to system resources, such as files and folders in the NTFS filesystem. You can assign Windows user accounts or groups to the ACL for a given resource to allow that user or group access to the resource, or determine what type of access (read, write, change, etc.) is authorized.
ACL-based authorization is useful primarily when using Windows authentication in ASP.NET. IIS uses the authenticated user identity to perform ACL checks and can also make requests for ACL-protected resources by using the user's security context, if impersonation has been enabled.
To protect a file using ACL authorization, right-click the desired file in Windows Explorer and select Properties. Next, click the Security tab to view the current users, groups, and permissions on the file (as shown in Figure 9-2). Use the Add and Remove buttons to add or remove user or group accounts and the checkboxes in the Permissions section to modify permissions for the selected user.
One of the first things you might do in this example is remove the Everyone group from the folder, since this group (as the name suggests) allows anyone who can access the computer to access this file.
URL authorization uses the <allow> or <deny> elements of the <authorization> configuration element to control access to folders and files within the application, as we saw in the example on Forms authentication. Access can be allowed or denied based on username, role, and/or HTTP verb used to request the resource. Thus, to allow user Marcie to access any resource in the application with any HTTP verb, but to prevent user Charles from making POST requests, we'd add the following <authentication> section to the web.config file at the root of the application (you can also add an <authentication> section to a web.config file in a child directory to override or add to these settings):
<authorization> <allow verb="GET" users="*" /> <allow verb="POST" users="Marcie" /> <deny verb="POST" users="Charles" /> <deny users="?" /> </authorization>
As we saw in Example 9-1, you can also use the <location> tag with the path attribute to control access to a specific folder or file:
<location path="filetoprotect.aspx"> <system.web> <authorization> <deny users="?"/> </authorization> </system.web> </location>
Because the <location> tag in web.config requires its own <system.web> tag pair, the <location> tag should always appear inside the <configuration> and </configuration> tags, but outside the <system.web> and </system.web> tags. You can define as many different <location> tags as you like, and each can contain its own URL authorization restrictions.
To specify domain rather than local accounts or groups, use the domainname\ userorgroupname format when specifying the name in the <allow> or <deny> element. There are two wildcards for users, both of which we've seen already. The asterisk (*) refers to all users, while the question mark (?) refers to anonymous (unauthenticated) users. Finally, multiple users or groups can be specified in the <allow> or <deny> elements by separating the list of users or groups with commas.
You can also perform programmatic checks at runtime to determine whether a user should be allowed to perform certain actions. The primary means of doing this is the IsInRole method, which is defined by the IPrincipal interface and accessible from the User property of the Page class. As with ACL-based authorization, this method is most useful when you're using Windows authentication and want to check whether the authenticated user belongs to a particular Windows group, such as a managers' group. The use of IsInRole is shown in the following code snippet:
If Page.User.IsInRole("Managers") Then 'perform some action restricted to managers Else Message.Text = "You must be a manager to perform this action" End If