Persisting windows authentication permission tokens, that allow later impersonation

Question

Think about a service like IfThisThenThat (IFTTT.com). In there, I authenticate against services (twitter, evernote, gmail, dropbox etc) and authorize IFTTT to act on my behalf (presumably by storing a token of some sort). I can revoke the token any time I want, if I no longer want to authorize IFTTT to impersonate me.

What if I wanted to do the same thing with windows authentication for internal services?

I imagine the user would visit a web page using windows authentication - and approve creating of some sort of token, that I can persist in a database. Then later, when I need to run something in the context of that user (like an internal web service), I would take the token and run some kind of impersonation code (trivial at least when you know the password).

What technology/concepts would be a good way to do this?

Answer 1

Well, Kerberos is used to log on to Windows machines and it actually does something very similar to what you describe already. When you log on, you are granted a ticket-granting ticket that can then be used to sign in to other services with the same account. However, Kerberos tickets expire within a narrow timeframe and a new one must be issued before the expiration if you want to avoid having to log on again. You cannot just store a Kerberos ticket in a database and use it again in a later session. It's specifically designed to prevent such use cases, so that if a ticket does eventually become compromised, it will be useless. Generally, tickets older than 5 minutes are rejected by default. Here's a link to the MSDN docs on Kerberos for much more detailed information on how this works:

MSDN: Microsoft Kerberos (Windows)

Having said all of this, Windows does allow system services to impersonate users already. If you're running as SYSTEM or a member of Administrators, you can call ZwCreateToken to create a token for pretty much any account. This article gives an in-depth description of how to use it (among a bunch of other things and providing a sample program.) Be warned that this is a pretty long article that goes into a lot of details regarding Windows logons and it's also kind of old. Its principles should still be true and the code should still work, though, as far as I know.