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.