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)
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."
Ads by The Lounge