Impersonation is usually performed for resource access control. With impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they're operating. We should carefully consider whether or not impersonation is required, as it consumes additional server resources.

 If impersonation is enabled, ASP.NET will receive the token to impersonate from IIS. You have more granular control of impersonation in a Web application when using ASP.NET in comparison to traditional Active Server Pages (ASP). This is controlled by specifying a value in the application's Web.config file.

There are three options when specifying the required impersonation setting:

• Impersonation enabled:
In this instance, ASP.NET will impersonate the token passed to it by IIS, which will either be an authenticated user or the anonymous Internet user account.

<identity impersonate="true"/>

•Impersonation enabled, with a specific impersonation identity specified:
In this instance, ASP.NET will impersonate the token generated using the configured identity. In this case the client token, if applicable, is not used.

<identity impersonate="true" name="domain\user" password="pwd"/>

• Impersonation is disabled:
This is the default setting for backward compatibility with ASP. In this instance, the ASP.NET thread will run using the process token of the application worker process, which by default is the IIS system account, regardless of which combination of IIS and ASP.NET authentication have been used.

<identity impersonate="false"/>

If the application resides on a UNC share, ASP.NET will always impersonate the IIS UNC token to access that share unless a configured account is used. If an explicitly configured account is provided, ASP.NET will use that account in preference to the IIS UNC token.