The Many Answers to My One ASP.NET Question
The core question in “An ASP.NET Question (or Two)” is (essentially) what is the relationship between the <identity /> element in web.config and WindowsImpersonationContext? There are several answers to this question of increasing complexity. This is the simplest answer: the <identity /> element makes the entire ASP.NET application impersonate the calculated user while the WindowsImpersonationContext causes the application to impersonate at the code-block level within a page or other handler.
The detailed answer to this question is almost completely addressed in “How To: Use Impersonation and Delegation in ASP.NET 2.0.” Several important items are in this paper. Leading is this:
Use basic authentication if you cannot use Kerberos authentication and delegation, and you cannot use LogonUser or protocol transition. For example, if you configure IIS to use integrated Windows authentication, it will use Kerberos authentication if possible, but otherwise default to NTLM authentication—which does not allow access to network resources with an impersonated identity.
My casual use of NTLM authentication dates back to my ASP days but this lack of delegation (yes, NTLM does not support delegation) means that the informal use of SSL (in “Easy way to setup SSL for testing on IIS”) and Active Directory (in “How To: Use Forms Authentication with Active Directory in ASP.NET 2.0”) should be added to my personal regimen of exercise. This means simply that my development IIS server should have SSL, Forms Authentication and Active Directory by default—instead of something to add later for some specific project.
What “How To: Use Impersonation and Delegation in ASP.NET 2.0” does not discuss is the <alwaysFlowImpersonationPolicy /> element. I’m just curious as to why this is not covered—yet another question! This element is introduced by the PowerShell team in “Impersonation and Hosting PowerShell.”