ASP.Net MVC - OWIN - 允許Windows /個人身份驗證

Question

我有一個ASP.Net MVC 5應用程序，目前使用個人身份驗證（帳戶/ l​​ogin.cshtml頁面沒有身份驗證/匿名訪問）和OWIN。工作正常。

由於這是一個Intranet應用程序，我希望允許用戶在他們的Windows帳戶，其他用戶Windows帳戶或應用程序帳戶（管理員，特殊用戶等）登錄 - 這些帳戶沒有關聯的域帳戶。

對於第一個選項，我想在登錄屏幕上顯示他們的Windows用戶名，他們只需點擊「確定」按鈕即可登錄。要獲取用戶名，我修改了Visual Studio項目屬性以禁用匿名身份驗證並啓用Windows身份驗證。還修改了web.config並將身份驗證模式設置爲Forms。這會導致「HTTP錯誤404.15 - 未找到」。這似乎是由於由OWIN引起的驗證循環，並帶有以下修復建議：

• 確保登錄控制器方法允許匿名訪問（默認情況下似乎是這種方式）。
• 或修改Startup.auth，註銷LoginPath屬性。
• 或者修改web.config，添加值爲「false」的appSetting「owin：AutomaticAppStartup」。

我選擇了LoginPath修復，這似乎工作（如web.config更改），因爲沒有錯誤，登錄頁面顯示與Windows用戶名（使用System.Threading.Thread.Currentprinciple檢索.Identity.Name）。

現在的問題是，一旦用戶登錄OwinContext沒有用戶（HttpContext.GetOwinContext（）。GetUserManager（））。

理想情況下，我不需要IIS或OWIN進行任何身份驗證，因爲它是由應用完成的 - 但我需要初始請求（對於帳戶/登錄頁面）包含Authenticate頭部，以便可以獲取Windows用戶。

首先我想了解是什麼導致「HTTP錯誤404.15」並修復。 其次，我如何讓OWIN與認證更改一起工作 - 我只是需要它來堅持用戶進行控制器認證。

Answer 1

這只是一個猜測，但我相信錯誤是由您描述的錯誤配置引起的：您已將身份驗證模式設置爲「Forms」，但將項目設置爲使用Windows身份驗證。它可能會令人困惑，但Windows身份驗證不是表單身份驗證。當你使用表單認證時，用戶提供表單中提交的憑證，並對用戶存儲進行驗證（包括所有的防僞功能）（我相信你使用的是ASP.NET身份驗證，這是默認的「個人身份驗證「設置），如果驗證成功，則設置的cookie將包含在響應中。這個cookie然後被用來認證更多的請求。

經Katana documentation確認，沒有內置的Windows身份驗證中間件 - 微軟只是假設應該使用IIS。這有效地阻止了我們從很容易結合Katana OWIN中間件供應商與Windows身份驗證。現在，關鍵詞很容易：我們仍然可以「繞過」它的方式。

不幸的是，它仍然是一個黑客：我還沒有找到一種方法來使認證「透明」（如在「」用戶打開登錄表單並且可以輸入AD帳戶憑證或個人帳戶憑證和一切正常工作「）。您需要爲每個Windows用戶維護個人帳戶記錄（就像您使用任何外部OWIN中間件（例如Google或Facebook）一樣）。您可以自動完成帳戶創建和關聯，並使其看起來透明。您可以爲Windows身份驗證添加一個「外部提供者」按鈕。

驗證用戶看起來像（在一個單獨的「AD認證」控制器）：

bool userWindowsAuthentication = Request.LogonUserIdentity.IsAuthenticated; 

if (userWindowsAuthentication) { 
    var userStoreDatabaseContext = new ApplicationDbContext(); 
    var userStore = new UserStore<UserModel>(userStoreDatabaseContext); 
    var userStoreManager = new UserManager<UserModel>(userStore); 
    var userWindowsLoginCredentials = GetWindowsLoginInfo(); 

    var existingInternalUser = userStoreManager.FindAsync(userWindowsLoginCredentials.UserName) 

    if (existingInternalUser) { 
     // It means that the user already exists in the internal provider and here you simply authenticate and redirect to destination 
    } else { 
     // It means that the user does not exist. You can automatically create the internal user record here and associate the Windows user with the internal record. 
    } 
} else { 
    // It means that user is not signed in using Windows authentication, so you either want to redirect back to the login page or restrict access or do something else 
} 

正如你可以看到，它的「髒」。另一個黑客：你可以有隻接受Windows身份驗證的附加層（單獨的應用程序或虛擬應用程序）。這個應用程序可以是您的登錄資源。如果用戶使用Windows AD進行身份驗證，則可以將其重定向到正確的登錄頁面。你可以走得更遠，並在重定向請求頭中添加他們的登錄信息，但如果你這樣做 - 頭部必須加密，以確保Windows身份驗證不能僞造，唯一應該能夠解密和驗證它的應該是你的主要應用。再次，骯髒，但工程。