The ASP.NET impersonation is totally controlled by entries in the applications web.config file. Default setting is "no impersonation". You can explicitly describe that ASP.NET shouldn't use impersonation by including the following code in the file as shown:
It means that the ASP.NET will not perform any authentication and runs with its own priority . By default the ASP.NET runs as an unprivileged account named ASPNET. You can modify this by making a setting in the processModel part of the machine.config file. Whenever you make this setting, it automatically applies to every site on the server. To the user a high-privileged system account instead of a low-privileged set the userName attribute of the processModel element to SYSTEM. Using this setting is a definite security risk,since it elevates the privileges of the ASP.NET process to a point where it can do bad things to the operating system.
When you disable impersonation, all the request will run in the context of the account running the ASP.NET: either the ASPNET account or the system account. This is true when you are using anonymous access or authenticating users in few fashion. After the user has been authenticated, the ASP.NET uses its own identity to request access to resources.
The second possible setting is to turn on impersonation.
In this situation , the ASP.NET takes on the identity IIS passes to it. If you are allowing anonymous access in the IIS, this means that ASP.NET will impersonate the IUSR_ComputerName account that IIS itself uses. If you aren't allowing anonymous access,ASP.NET will take on credentials of the authenticated user and made requests for resources as if it were that user. Hence by turning impersonation on and using a non-anonymous method of authentication in IIS, you can let users log on and use their identities within your ASP.NET application.
Finally, you can specify a particular identity to use for all authenticated requests
With this setting, all the requests are made as the specified user (Assuming that the password it correct in the configuration file). So, for e.g. you can designate a user for the single application, & use that user's identity every time someone authenticates to the application. The main drawback to this method is that you must embed the user's password
In the web.config file in the plain text. Although the ASP.NET won't allow anyone to download this file, this is still a security risk if anyone can get the file by some other means.