| Impersonation allows ASP.NET to execute pages with the identity of the client on whose behalf it's operating. In other words, if a user is authenticated with the identity clpayne, ASP.NET will restrict or deny access based on that user's permissions. Wait a minute. Isn't that what normally happens anyway? Let's take a look at Figure 21.11 to make more sense of this. Figure 21.11. The process flow when impersonation is enabled.
By default, impersonation is disabled. As the user moves from IIS authentication to the ASP.NET application, ASP.NET itself takes on the identity that IIS is configured to use (by default, this is the "Local Machine" identity). Typically, this identity has permission to access all files and folders. Other security measures must be used to handle access, such as URL authorization. When impersonation is enabled, ASP.NET takes on the role of the identity that IIS passes to it, rather than the one IIS is using for itself. If the user is unauthenticated, ASP.NET will impersonate the anonymous user, and if the user is authenticated, ASP.NET will take on that identity. Now that ASP.NET is impersonating another user, Windows can restrict access to the application as a whole by using ACLs. An ASP.NET application is a user of the system's resources. It accesses files and folders, memory, and so on. By default, the ASP.NET application process has fairly liberal permissions, and generally can access everything the system has to offer. This is necessary because ASP.NET must use these resources to operate correctly. However, you may want to restrict access to certain resources, depending on the person who's using the ASP.NET application. For example, an anonymous user shouldn't be able to take advantage of the application's permissions and access all of the system's resources. Thus, an ASP.NET application can impersonate its users in order to restrict access. When ASP.NET impersonates a user, it acts like that user in every way. In fact, the operating system will believe that ASP.NET is that particular user accessing the resources. The access control lists now apply and can restrict access to both ASP.NET and the user. Let's imagine a typical scenario with impersonation enabled. A registered but non-administrative user named JoeSchmoe visits your site. As soon as JoeSchmoe is authenticated, ASP.NET assumes his identity, and all code is executed under his account. One page on your site, files.aspx, lists all the files on the server computer for administrative purposes. Naturally, only administrative users should be able to access this page. If JoeSchmoe tries to access this page, ASP.NET (now impersonating JoeSchmoe) won't be able to execute the code because it doesn't have permission to read every file on the server under JoeSchmoe's account. Thus, impersonation stops users from accessing files to which they aren't allowed access. Shouldn't ASP.NET automatically provide this capability, however? The answer is no. By default, ASP.NET assumes that other authentication and authorization methods are used, and impersonation isn't necessary. For example, using Windows authentication, you would stop users from accessing resources before they could even reach the page in question. Impersonation isn't necessary here because the user never gets to try to execute the code. If there is a chance, however, that a user could access a file that she shouldn't be able to, impersonation is very helpful. Note Even with impersonation, ASP.NET still uses its regular identity to access configuration information. Otherwise, the application wouldn't function properly. For example, most users don't have access to files such as the machine-level machine.config file, which contains information on configuring all ASP.NET applications.
So, why wouldn't you want to use impersonation, if it offers a convenient way to control access? Recall that managing permissions with ACLs can be troublesome. Often you'll want to implement another method of authorization, such as URL authorization. Also, to use impersonation, you need to use IIS to authenticate your users, which is a necessity some would rather not deal with. | Do | Don't | | Do use impersonation if you don't want to spend time writing ASP.NET code. With impersonation, you only need to set IIS authentication and manage the ACLs. | Don't use impersonation if you'd rather build the authentication system yourself. | |
Enabling impersonation is very simple. You just need to add a single line to the web.config file: <configuration> <system.web> <identity impersonate="true" username="user" password="pw" /> </system.web> </configuration> The only required attribute is impersonate. Set it to True to enable impersonation, or False otherwise. The optional username and password attributes specify that ASP.NET should always impersonate a certain user, rather than the IIS-authenticated user. This is useful if all users should have a defined set of permissions that is, if no one user will have more permissions than another. For example, suppose that you have many Windows identities, all of which should have the same permissions. Due to the time required to manage the ACLs for each file and user, you've set the correct permissions for only one user. Now, any of these users can be authenticated through IIS, and they all can impersonate the one user that has the correct permissions, thus saving you quite a bit of time. Another example would be if a user identity resides on another computer on the network domain. After a user is authenticated on the server machine, ASP.NET could impersonate an account on a separate machine, which might have different permissions than the authenticated user. This simple setting will allow ASP.NET to impersonate an incoming user and use the Windows ACLs to restrict access. | 
