Avoid using Impersonation in ASP.NET
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.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGGuidelines0001.asp)
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;
3:
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: }
12:
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.
About Newsletter
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.