Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
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.
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.
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 :)!
If these articles: How To: Implement Kerberos Delegation for Windows 2000 How To: Use Impersonation and
If these articles: How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0 Using Protocol
Windows Authentication Identity Flow Through Physical Tiers Identity Flow Through Physical Tiers - Impersonation
I was delivering "Authentication Explained" session for Security User Group. First of - thanks for attending
I was delivering "Authentication Explained" session for Security User Group. First of - thanks