c# - What does WindowsIdentity.GetCurrent().Impersonate() do

I am writing a class to handle impersonation and delegation for use in in asp.net, WCF services, and WinForms apps.

Per MSDN, WindowsIdentity.GetCurrent() returns a WindowsIdentity object that represents the current Windows user.

And

Per MSDN, WindowsIdentity.Impersonate allows code to impersonate a different Windows user.

So, what effect does impersonating the current user have, and more importantly, in a web app, how can WindowsIdentity.GetCurrent() return other than the process starter identity or the already impersonated end user?

网友答案:

Impersonate() throws a SecurityException if a Win32 error occurs. Therefore, chances are it's implemented through a Win32 function, most probably ImpersonateLoggedOnUser().

Its documentation says (emphasis mine):

All impersonate functions, including ImpersonateLoggedOnUser allow the
requested impersonation if one of the following is true:

The requested impersonation level of the token is less than SecurityImpersonation, such as SecurityIdentification or
SecurityAnonymous.

The caller has the SeImpersonatePrivilege privilege.

A process (or another process in the caller's logon session) created the token using explicit credentials through LogonUser or
LsaLogonUser function.

The authenticated identity is same as the caller.

Therefore, I'm strongly inclined to think that WindowsIdentity.GetCurrent().Impersonate() will successfully establish a new impersonation layer to the same user.

Concerning the second part of your question, you seem to be confusing WindowsIdentity.GetCurrent() with HttpContext.User. In a web application, WindowsIdentity.GetCurrent() always returns the thread owner (usually Network Service), and HttpContext.User returns the currently authenticated user, if any.

网友答案:

The current user is important if you have to run a user through multiple applications, including some that would normally allow anonymous access, as well. In addition, it allows you to explicitly do what is done implicitly in certain types of applications.

From your standpoint, the more important thing may be to understand that not all application types automatically get the startup user type in the manner you would like. In these cases, there are some instances where you can programmatically accomplish getting identity and then using it for your own means (nefarious or otherwise?).

As far as impersonating another user, that gets to be interesting when you get outside of some of the declarative situations (like ASP.NET impersonation). This is for good reason, so a hacker does not create an application with God like rights, for example.