asp.net模擬身份：它來自哪裏？

Question

這是一段簡單的問題，我一直在堅持。

當我在我的web.config中設置< identity impersonate=true >，以便asp.net自動模擬登錄的用戶（或者匿名帳戶，如果不使用Windows身份驗證），asp.net模擬身份從哪裏來？

此文件：http://msdn.microsoft.com/en-us/library/ff649264.aspx顯示了三個地方，你可以檢索有關登錄的用戶信息：

Httpcontext.Current.user

System.Threading.Thread.Current

System.Security.Principal.WindowsIdentity.GetCurrent

看來，沒有這些位置的一致匹配身份，當我在web.config中設置< identity impersonate=true >時被模仿。

我想知道模擬身份的來源。

具體來說，我的意思是詢問低層次，在運行時確切地從何處獲取身份。我熟悉IIS的配置，但我想知道如何在運行時檢索身份，以及它來自哪裏。爲了便於討論，我們假設身份是在IIS中設置的，而不是在web.config文件中設置的。

Answer 1

您不能將模擬部分與認證部分分開。我想你知道，因爲你寫

... asp.net假冒自動登錄的用戶（或匿名帳戶，如果不使用Windows身份驗證）...

但我很困惑由句子

爲了便於討論，我們假設身份是在IIS中設置的，而不是在web.config文件中設置的。

你究竟是什麼意思？

但讓我有在回答一個鏡頭反正：
讓我們假設你是在Web.config中使用IntegratedWindowsSecurity，<identity impersonate=true>和<authentication mode=Forms>。這將對應於您引用的Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication中最後一個表格的倒數第二行。

它指出在這種情況下Domain\UserName將從WindowsIdentity返回。我想你很想知道Domain\UserName -Identity來自哪裏...使用Kerberos有一些限制，比如IE將URL分類爲「Intranet」或「Local」，但我認爲這並不重要。

現在區分在Web.config中設置<authentication mode=windows>並在IIS中將訪問模式設置爲IntegratedWindowsSecurity（或任何它所調用的）是很重要的。在上述鏈接的最後一個表格中，我們將IIS設置爲IntegratedWindowsSecurity（但我們可以在Web.config中設置<authentication mode="windows">！）。因此，IE與IIS就如何驗證當前登錄的用戶進行協商。使用NTLM或Kerberos（主要取決於Windows版本）。那是Domain\UserName的來源。

下面的文章（談論代表團，我知道）可能會揭示問題ASP.NET Delegation越光：

集成Windows身份驗證

當Internet Explorer嘗試 訪問受保護的資源，IIS將發送 兩個WWW-Authenticate頭文件到 瀏覽器，Negotiate和NTLM。 協商標頭僅由在Windows 2000或更高版本上運行的IIS 發送。此 標頭指示IIS支持 協商協議，該協議允許在因特網 Explorer和IIS之間進行 協商，以確定是否使用 Kerberos或NTLM身份驗證。 IIS 使用Kerberos如果客戶機 （Internet Explorer 5.0及更高版本）和 服務器（IIS 5.0及更高版本）運行 Windows 2000或更高版本，兩者都是同一個域的成員 或可信 域。否則，服務器 默認使用NTLM。

由於NTLM而不提供用戶的 憑據IIS認證爲 IIS用戶，IIS不能 代表該用戶的憑證提供給 遠程機器。

當使用Kerberos V5 驗證配合使用時，IIS可以委派運行Windows 2000被 信任，配置爲使用委派電腦 或更高版本中 安全證書。

你可能知道這些鏈接，但我無論如何張貼：

• ASP.NET Impersonation
• ASP.NET Process Identity

編輯：
要多一點精確我認爲（不確定這裏）那個IIS cre使用解釋爲here in msdn的構造函數從LogonToken（通過調用非託管Win32 LogonUser函數獲得的那個）執行WindowsIdentity。此外，WindowsIdentity Class文檔中的示例代碼非常有趣（例如，IntPtrStringTypeConstructor）。然後登錄令牌必須來自IE。

Scott Hanselman寫了一篇類似的文章：System.Threading.Thread.CurrentPrincipal vs. System.Web.HttpContext.Current.User or why FormsAuthentication can be subtle。

我認爲如果您尋找將「自定義主體」對象「植入」ASP.NET身份驗證過程（通常在Global.asax中使用Application_AuthenticateRequest）的解決方案，您可能會提取其他信息。例如Using Custom Principal with Forms Authentication in ASP.NET。

或者你可以使用Reflector，看看自己:)

Answer 2

如果我沒有弄錯，這是在IIS中設置的身份。目錄安全。

Answer 3

在過去，我設置了身份來模擬在 web.config文件中。 在這種情況下，我創建了一個用戶，將應用程序池設置爲在該用戶下，並使用該用戶名進行模擬。

Answer 4

啓用模擬時，身份來自IIS。會發生什麼是ASP.NET模擬IIS提供的訪問令牌。

用於啓動進程的原始訪問令牌仍可用。這可能是圍繞使用問題中提到的三個API的混淆的根源。

Thread.CurrentPrincipal & HttpContext.Current.User：線路另一端的用戶身份。

• 這是通過模擬令牌傳遞給ASP.NET的信息
• 此令牌將動態創建的基於身份：
• 是：a）用戶在（表格與Windows身份驗證登錄如何），
• 或者：b）模擬用戶名設置在web.config中。

WindowsIdentity.GetCurrent：正在執行的實際底層Windows帳戶。

• 這就是在ASP.NET開始模擬之前啓動該過程的方式。
• 這隻會是一個WindowsIdentity。

原因在HttpContext.Current.User複製是一個方便的ASP.NET開發人員。

編輯：

當IIS配置爲在集成Windows身份驗證運行，和 ASP.NET已啓用了模擬，下面的代碼將使我們能夠運行代碼作爲基本賬戶。

[DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
public static extern bool RevertToSelf(); 

protected void Page_Load(object sender, EventArgs e) 
{ 
    var me = WindowsIdentity.GetCurrent(); 

    // At this point: 
    // me.Name = Domain\UserName 
    // me.AuthenticationType = Kerberos 

    if (RevertToSelf()) 
    { 
     var underMe = WindowsIdentity.GetCurrent(); 
     // At this point: 
     // underMe.Name = IIS APPPOOL\DefaultAppPool 
     // underMe.AuthenticationType = Negotiate 
    } 
} 

取決於你正在嘗試做的，這個頁面有攻擊問題的更多的方式：如果您在您的應用程序，首先要影響其在該實體的關注http://support.microsoft.com/kb/306158

Answer 5

需要注意的是您的身份驗證模式（Windows，Form，Passport或None）

從證書讀取以驗證您的請求的地方取決於您的應用程序選擇的身份驗證模式。