Scott Hanselman

Avoid using Impersonation in ASP.NET

October 24, 2006 Comment on this post [2] Posted in ASP.NET
Sponsored By

The MSDN Docs are very careful not to recommend using impersonation it affects connection pooling when talking to databases downstream. The suggestion that one takes care when using impersonation has been in place since its inception.

Know Your Tradeoffs with Impersonation

Be aware that impersonation prevents the efficient use of connection pooling if you access downstream databases by using the impersonated identity. This impacts the ability of your application to scale. Also, using impersonation can introduce other security vulnerabilities, particularly in multi-threaded applications, such as ASP.NET Web applications.

You might need impersonation if you need to:

· Flow the original caller's security context to the middle tier and/or data tier of your Web application to support fine-grained (per-user) authorization.

· Flow the original caller's security context to the downstream tiers to support operating system level auditing.

· Access a particular network resource by using a specific identity.


ScottGu has a good post on how to use declarative authorization to restrict access without impersonation. This works great with Forms Authentication and Custom Principals like we use at Corillian. Here's one of his examples:

   1:  using System;
   2:  using System.Security.Permissions;
   4:  [PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
   5:  public class EmployeeManager
   6:  {
   7:      [PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
   8:      public Employee LookupEmployee(int employeeID)
   9:      {
  10:         // todo
  11:      }
  13:      [PrincipalPermission(SecurityAction.Demand, Role = "HR")]
  14:      public void AddEmployee(Employee e)
  15:      {
  16:         // todo
  17:      }
  18:  } 

There's all sorts of wacky things one can do with impersonation, but it you ask yourself WHY you need it, perhaps you'll find a simpler solution.

One of my bosses always says "Guy walks into support, sez he needs a bigger mobile phone antenna. Doe he need a bigger antenna or does he really want better reception? Don't let your users dictate your solution with their statement of the problem."

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
October 24, 2006 23:11
The only time I have ever needed to use impersonation was to query the Indexing Server. Any ideas on how I can get around this?
October 26, 2006 7:03
This was actually a question on an MCP exam I took a few months ago... Wish I could remember which one. :)

Insofar as internal applications, our network doesn't have a working Kerberos implementation, so impersonating the user to the database has never been a real viable option for us... At least, that is, using Windows authentication via IE - I'm well aware that you can use basic HTTP authentication and then ASP.NET can happily impersonate anybody, and then the connection pooling thing applies.

Scott, what about when you specify an identity to impersonate in your web.config? Our DBAs have it out for SQL authentication and want everything to use Windows auth, even if it's just a single application account, so that's how we've been doing it. I wouldn't think that would have any impact on connection pooling, but stranger things have happened...

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.