Partager via

Identity Flow Through Physical Tiers - Impersonation

  • Article

There are scenarios where actual windows identity  of end user needs to be flowed to the server so that server can perform action on end user's behalf - that is in nutshell Impersonation. In previous post Identity Flow Through Physical Tiers - one might think that the end user identity flowed but in fact it was not. Although HttpContext held end user's account - DEMO\Administrator - and even identity's type was WindowsIdentity, the actual windows thread was ran under Application Pool's account - DEMO\W3WRUNNER1. That means that the resources were accessed under App Pool account - DEMO\W3WRUNNER1 - just as depicted in the post.

While scenario is the same where user sits behind her machine A and access simple ASPX page on box B that access file on share on box C, like this:

lets do some small changes, and define impersonation in web.config file:

Now lets access the aspx page:

Seems like impersonation works - both HttpContext and windows thread has the same, end user's identity - cool, good job.

But when the code reaches the line where the file on share (Box C) is accessed, something goes wrong:

 

Why? It worked in previous post...

The reason for such behavior is that I got my architecture confused...

On one hand I asked app process, sorry, specific request's thread to run under end user's account - Impersonation - by setting impersonate="true" in web.config. On other hand I ask this thread to go out to network resource - my file on file share. That is another Impersonation... In scenario where the resource sits on the same box, Web Server B, impersonation would work, but in our case - the resource sits on other machine C.

In other words  I am trying to flow identity over two hops - from end user machine A to web server B and then to File share C - that is more than Impersonation, but Delegation which will be discussed in the next post.

Comments

  • Anonymous
    April 07, 2007
    I ran into this problem (also referred to as the double hop issue with NTLM) a long time ago. Kerberos is the non trivial solution to this. I have a web app calling webservices hosted on another machine and I needed the identity of the user accessing the web app in the web services layer. It took me quite a while to get the Kerberos working. But I am glad to see someone from MS blogging about it.
  • Anonymous
    April 07, 2007
    Kris, I am happy you got your app running. There is no issues with double hop with NTLM - it just does not work :)Notice "Authentication type" is "Negotiate" in the picture - that is kerb, otherwise it'd be NTLM.To pass identity over more than one hop one needs  Delegation which supported only by kerb - and that is what my next post is just about, that would be followed by Protocol Transition.Stay tuned and happy coding :)!
  • Anonymous
    April 08, 2007
    If these articles: How To: Implement Kerberos Delegation for Windows 2000 How To: Use Impersonation and
  • Anonymous
    April 10, 2007
    If these articles: How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0 Using Protocol
  • Anonymous
    April 11, 2007
    Windows Authentication Identity Flow Through Physical Tiers Identity Flow Through Physical Tiers - Impersonation
  • Anonymous
    July 04, 2007
    I was delivering "Authentication Explained" session for Security User Group. First of - thanks for attending
  • Anonymous
    July 04, 2007
    I was delivering "Authentication Explained" session for Security User Group. First of - thanks