關於 web.config impersonate 帳號模擬
元素，可以使其impersonate屬性為true來設定本應用程式的身份，從而達到扮演其他賬號身份的目的。而具體的“扮演”有兩種方式：
（1）、<identity impersonate="true" />
這種方式的話ASP.NET程序將扮演http/https請求者的身份。而具體是什麼帳號，就跟IIS的安全性設定有關了：
如果IIS允許匿名訪問，那麼被扮演的將是Iuser_Machine帳號（因為預設的匿名訪問賬號是Iuser_Machine，當然如果修改過，那被扮演的就是修改過的帳號）。
如果IIS不允許匿名訪問，那麼瀏覽器請求者的身份肯定是一個Windows帳號，這個帳號就是被扮演的物件。
（2）、<identity impersonate="true" userName="Account" password="Password"/>
這種方式就直接設定所扮演的固定使用者身份
第（2）種扮演方法將把password明文的寫在Web.Config裡，很不安全
PS1：微軟不推薦使用扮演，無論扮演哪個帳號，一方面是安全性問題（被扮演的帳號可能有一些程式並不需要的多餘許可權，可能被利用），另一方面是可伸縮性問題（Scalability），因為在訪問SQL Server等資源時，無法利用連線池等手段。
PS2：在\%windows%\Microsoft.NET\Framework\Version\Config目錄中找到machine.config檔案，其中有一個<processModel>的tag:
<processModel enable="true" ... userName="machine" password="AutoGenerate" ... />
其中的userName="machine"就是指定使用本機ASPNET帳號（.\ASPNET）作為ASP.NET工作程序的預設賬號。
這個預設帳號是可以修改的，如果開發人員將userName修改為一個域使用者帳號：
<system.web>
<processModel enable="true" userName="domain\user" password="password"/>
</system.web>
那麼ASP.NET工作程序的身份就變成了domain\user。只要這個域使用者帳號擁有需要的許可權，那麼machine.config所在機器上所有ASP.NET程式都可以訪問域中其他伺服器的資源，包括存取用網路共享路徑指定的檔案。
如果指定userName="system"，那麼ASP.NET程式將以LocalSystem身份執行，可以存取幾乎所有本地資源，因此非常危險！
無論machine.config指定哪個預設帳號，這個預設帳號都可以被應用程式的web.config設定的Impersonation覆蓋，即特定應用程式可以以其他身份執行。