Help understanding impersonation

Question

Could somebody please help me understand the concept of 'impersonation'?

The way I understand it is that when impersonation occurs, code executes on behalf of some identity.

So, for a web page, as long as impersonation is disabled, the web page will always run under its configured account.

If it’s enabled, I can ‘override’ its default account and set the account under which I want the web application to run.

So if I'm using IIS7 and I have the following:
- An application pool with identity set to a Custom account ‘user1’.
- An asp.net web site, with its application pool set to the one above, and with impersonation disabled.
- Windows authentication enabled.

I also have the following code:

IIdentity ii= Thread.CurrentPrincipal.Identity;
IIdentity iii = Page.User.Identity;

If I access the page, I’m asked for windows credentials, I introduce ‘user2’ credentials.

As impersonation is disabled, I’d expect the IIdentity name to be ‘user1’, which it isn’t its ‘user2’.

Can somebody help me understand what’s going on? I guess I completely misunderstand the concept of ‘impersonation’.

Thanks

UPDATE 1

I came across this link after searching for a while: http://msdn.microsoft.com/en-us/library/aa302377.aspx

It seems like there are three IIdentity objects.

HttpContext.Current.User.Identity
Thread.CurrentPrincipal.Identity
WindowsIdentity i2 = WindowsIdentity.GetCurrent();

From the link I understand that:

HttpContext.Current.User.Identity: Represents the current user requesting the page.

Thread.CurrentPrincipal.Identity: Identity currently executing the thread. I guess that this identity will be the one under which the current web request runs and its asp.net roles will define what the user can and can’t do in the application.

I suppose most of the times both HttpContext.Current.User.Identity and Thread.CurrentPrincipal.Identity would be the same user, but for some scenarios I guess the user requesting the page and the Thread.CurrentPrincipal.Identity could be different.

Then there’s: WindowsIdentity i2 = WindowsIdentity.GetCurrent();

The link says: “WindowsIdentity = WindowsIdentity.GetCurrent(), which returns the identity of the security context of the currently executing Win32 thread.”

After doing a few tests enabling a disabling ‘impersonation’ and for my current scenario, I find that this is the Identity that gets impersonated.

If I don’t impersonate, ‘WindowsIdentity.GetCurrent();’ would reflect the configured user in the application pool and if I do impersonate, the identity changes to the one I’ve set in web.config:

<identity impersonate="true" password="**" userName="****" />

UPDATE 2

And if I set the web.config as: <identity impersonate="true" />

WindowsIdentity.GetCurrent() gets impersonated as the user making the request so:

HttpContext.Current.User.Identity
Thread.CurrentPrincipal.Identity
WindowsIdentity.GetCurrent()

Are the same user, the user requesting the page.

Answer 1

When using impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they are operating. The usual reason for doing this is to avoid dealing with authentication and authorization issues in the ASP.NET application code. Instead, you rely on IIS to authenticate the user and either pass an authenticated token to the ASP.NET application or, if unable to authenticate the user, pass an unauthenticated token.

From Very good Article ASP.NET Impersonation