Impersonate original caller only when required

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

By default, ASP.NET applications usually do not impersonate the original caller for design, implementation, and scalability reasons. For example, impersonating prevents effective middle-tier connection pooling, which can have a severe impact on application scalability.

In certain scenarios, you might require impersonation (for example, if you require an alternate identity (non-process identity) for resource access). In hosting environments, multiple anonymous identities are often used as a form of application isolation. For example, if your application uses Forms or Passport authentication, you can impersonate the anonymous Internet user account associated by IIS with your application's virtual directory.

You can impersonate the original caller, which might be the anonymous Internet user account or a fixed identity. To impersonate the original caller (the IIS authenticated identity), use the following configuration:

<identity impersonate="true" />

To impersonate a fixed identity, use additional userName and password attributes on the <identity> element, but make sure you use Aspnet_setreg.exe to store encrypted credentials in the registry. For more information about encrypting credentials in configuration files and about Aspnet_setreg.exe, see Chapter 19, "Securing Your ASP.NET Application and Web Services." at

Note In ASP.NET 2.0, you can use the Protected Configuration feature to encrypt the configuration section in the configuration file. For more information on using the Protected Configuration feature in ASP.NET 2.0, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI " at and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA" at


Personal tools