Question

Here’s a simple question I’ve been stuck on for a while.

When I set < identity impersonate=true > in my web.config so that asp.net impersonates the logged on user automatically (or the anonymous account if not using Windows Authentication), where does the identity that asp.net impersonates come from?

This document: http://msdn.microsoft.com/en-us/library/ff649264.aspx shows three places you can retrieve information about the logged on user:

Httpcontext.Current.user

System.Threading.Thread.Current

System.Security.Principal.WindowsIdentity.GetCurrent

It seems that none of these locations consistently match the identity that gets impersonated when I set < identity impersonate=true > in web.config.

I would like to know where the impersonated identity comes from.

Specifically, I mean to ask at a low level, where exactly does the identity get retrieved from at run-time. I am familiar with the configuration of IIS, but I want to know how the identity is retrieved at run-time and where it comes from. For the sake of discussion, let’s suppose that the identity is set in IIS, not in the web.config file.

Answer 1

You cannot separate the impersonation-part from the authentication-part. I think you know that since you write

… asp.net impersonates the logged on user automatically (or the anonymous account if not using Windows Authentication)…

But I am confused by the sentence

For the sake of discussion, let’s suppose that the identity is set in IIS, not in the web.config file.

What exactly do you mean by this?

But let me have a shot at an answer anyway:
Let’s assume you are using IntegratedWindowsSecurity, <identity impersonate=true> and <authentication mode=Forms> in Web.config. This would correspond to the second-last row of the last table in Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication which you cited.

It states that Domain\UserName will be returned from WindowsIdentity in this case. And I assume you are wondering where that Domain\UserName-Identity comes from… There are some restrictions on using Kerberos like IE has to classify the URL as “Intranet” or “Local” but I think this is not important here.

Now it is important to distinguish between setting <authentication mode=windows> in Web.config and setting the access mode to IntegratedWindowsSecurity (or whatever it is called) in IIS. Being in the last table of aforementioned link we are in the situation of IIS being set to IntegratedWindowsSecurity (nevertheless we can set <authentication mode="windows"> in Web.config!). So IE negotiates with IIS on how to authenticate the currently logged in user. Either using NTLM or Kerberos (mainly depending on the Windows version). That is where the Domain\UserName comes from.

The following article (talking about delegation, I know) might shed more light on the issue ASP.NET Delegation:

Integrated Windows Authentication

When Internet Explorer attempts to
access a protected resource, IIS sends
two WWW-Authenticate headers to the
browser, Negotiate and NTLM. The
Negotiate header is only sent by IIS
running on Windows 2000 or later. This
header indicates that IIS supports the
Negotiate protocol, which enables a
negotiation to occur between Internet
Explorer and IIS on whether to use
Kerberos or NTLM authentication. IIS
uses Kerberos if both the client
(Internet Explorer 5.0 and later) and
server (IIS 5.0 and later) are running
Windows 2000 or later, and both are
members of the same domain or trusted
domains. Otherwise, the server
defaults to using NTLM.

Since NTLM authenticates the user for
IIS without providing the user’s
credentials to IIS, IIS cannot
delegate that user’s credentials to a
remote machine.

When used in conjunction with Kerberos
v5 authentication, IIS can delegate
security credentials among computers
running Windows 2000 or later that are
trusted and configured for delegation.

You probably know these links but I am posting them anyway:

• ASP.NET Impersonation
• ASP.NET Process Identity

EDIT:
To be a bit more precise I think (not sure here) that IIS creates the WindowsIdentity from a LogonToken (the one you get by calling unmanaged Win32 LogonUser function) using the constructor explained here in msdn. Also the example code in the documentation of the WindowsIdentity Class is quite interesting (IntPtrStringTypeConstructor for example). The logon token would have to come from IE then.

Scott Hanselman wrote about a similar thing also: System.Threading.Thread.CurrentPrincipal vs. System.Web.HttpContext.Current.User or why FormsAuthentication can be subtle.

And I think you might be able to extract additional information if you look for solutions to “implant” a custom principal object into ASP.NET authentication process (usually using Application_AuthenticateRequest in Global.asax). Like Using Custom Principal with Forms Authentication in ASP.NET for example.

Or you can use Reflector and see for yourself 🙂