Most of what I am going to write comes from
here. I'll try to put it in plain English :)
You're doing impersonation, in technical terms you're trying to obtain an impersonation token that lets you impersonate and access network resources. There're multiple ways to achieve that.
Call LogonUser and request an Interactive logon session: you need a username and password and to do an interactive logon. This is not our scenario.
Use BASIC authentication and impersonation: this is straightforward if you're doing BASIC auth, you take the user's username and password out of the header and do a network logon, then impersonate. Waffle's BASIC auth filter does that (minus
the impersonate call) to validate the user's credentials - then it just disposes of the obtained impersonation token.
Kerberos authentication and delegation: if the protocol chosen by the client is Kerberos and several other conditions are satisfied (your computer or service account is Trusted for Delegation in Active Directory and you have registered a
Service Principal Name (SPN) for the service), what you get out of Waffle is a Kerberos TGT. You never see it, it's somewhere within the IWindowsIdentity that you obtained by implementing the server side of the Negotiate protocol (that's what Waffle does).
You get an impersonation token just like out of any logon. Then you call impersonate, the rest of the magic happens in Windows.
Use Protocol Transition: when the client can't do Kerberos (eg. your server is not in an Active Directory or you're logging in with a local account or there's no SPN configured properly) you'll be doing NTLM (v2). The Negotiate protocol
"negotiates" whether to do Kerberos or NTLM. Then, if certain conditions are satisified (described
here) you can impersonate and call the remote service on behalf of the user. It's the same Impersonate process, except the token you were holding after NTLM looks nothing like the token
that you got when doing Kerberos.
This entire thing boils down to an Impersonate call which puts your current Win32 thread into the context of the calling user - then you see what happens. This is all hidden from you by an API called SSPI, which makes Windows into a truly extensible authentication/impersonation/delegation