Authorizing Users

Windows Authentication provides a familiar model for working with user accounts that extends to authorization as well. Windows Authentication works both with and without impersonation enabled, but in slightly different ways.

As mentioned earlier, requiring that a user be authenticated is only part of the story in securing a Web application. Once the identity is established, this identity can be used to determine whether the user is authorized to visit parts of the application or carry out certain functions. The application can be customized easily so that sensitive data is not shown to users without clearance. The choices available for authorization follow along the same lines as those available for authentication. In fact, some authorization features work only when used in conjunction with the appropriate authentication mechanism.

File Authorization

In the “Windows Authentication” section earlier in this chapter, you learned that a request is handled by a worker process. It follows, then, that access to the .aspx files is controlled by setting access control lists (ACLs) for the identity of the worker process. ASP.NET can take this one step further by enforcing the NTFS file permissions for the authenticated user. This enforcement requires Windows Authentication but not impersonation. Recall that when using impersonation, the page code will execute as it would with the authenticated user; however, this authentication is independent of access to the file. One of the modules installed by default in the processing pipeline is the System.Web.Security.FileAuthorizationModule. It takes the credentials for the request that are passed from IIS and validates that the user has authorization to load the .aspx file before executing that request. If access has not been granted for that user account, ASP.NET returns an access denied message.

Tip

File Authorization works only against file types that are mapped in the Internet Services Manager to ASP.NET. File types that are not handled by ASP.NET will be subject to the IIS authorization checks.

URL Authorization

A different module in the pipeline is responsible for authorizing users for the requested URL based on configuration data. In many scenarios, this authorization can free us from adding explicit role membership checks in code. The System.Web.Security.UrlAuthorizationModule does not require that you specify any type of authentication. It examines the user and makes a decision based on the rules in the authorization element of machine.config and web.config. Code Listing 8-9 is a web.config file that overrides the machine.config default of allowing all users access. It uses the special wildcard ? to represent non- authenticated identities. If you haven’t enabled Windows Authentication in both IIS and ASP.NET, the user will simply get an access denied message. If you are using Forms Authentication, the user will be redirected to the loginUrl.

Code Listing 8-9: DenyAnonymous_Web.config

 <configuration>
    <system.web>
        <authorization>
            <deny users="?" />
        </authorization>
    </system.web>
</configuration> 

Of course, denying the anonymous user access just enforces the rule that the user must be authenticated. The configuration system will provide the authorization settings from individual directories to the UrlAuthorizationModule object. Whole directories of content can easily be restricted to individual groups in this way.

In addition to ?, the * is used as a wildcard to represent all users. The format for the users and role strings depends on the type of authentication being used. For Windows Authentication, you specify users as a comma-separated, domain-qualified list, such as “Domain\User1, Domain\User2.” Roles are specified the same way: “Windows\Administrators.” When using Forms Authentication, the user names and role names should match the identities stored in the HttpContext.User class.

Caution

Allow and deny tags are processed sequentially by ASP.NET. The first match found is used, so if you allow a user with one statement and deny them with another, the order of elements will determine whether the user gains access.

Code Listing 8-10 is a web.config file that demonstrates denying access to all users except users belonging to the superusers group and a person named Bob. The anonymous user or all users must be denied access in order to take advantage of authentication.

Code Listing 8-10: Authorization_Web.config

 <configuration>
    <system.web>
        <authentication mode="Forms" />
        <authorization>
            <allow roles="superusers" />
            <allow users="Bob" />
            <deny users="*" />
        </authorization>
    </system.web>
</configuration>