我應該如何在ASP.Net MVC網站中進行身份驗證？

Question

我有一個網站有一個需要驗證的區域。現在我使用該區域中所有控制器上的角色屬性，然後運行查詢以檢索該用戶標識及其所有設置。

這似乎是一個代碼或設計的氣味，我正在檢索userid和設置每當該地區的控制器加載？我不確定我是否應該使用會話，或者如果ASP.Net MVC 2.0提供了一些獨特的方式來處理這個問題。另一個擔憂是安全。

總的來說，我不知道該怎麼轉。設計明智，我想只有當用戶登錄到該區域時才檢索userId和設置。現在我每次控制器加載時都抓住userId，然後如果需要的話，我每次都要查詢數據庫的設置。

Answer 1

關於安全性的規則之一是你不應該自己去做。在沒有漏洞或後門的情況下正確地執行認證系統有許多缺陷。因此，在這方面，您可能會考慮.NET附帶的SqlMembershipProvider。它可以與MVC一起使用，並提供獲取角色和當前安全上下文的手段，易於設置和配置，並且比自己的更安全。

如果您不使用SQL Server，您有幾個選擇。一種解決方案是使用諸如SQL Server Express或SQL Server Compact Edition來維護證書。另一種解決方案是模仿SqlMembrershipProvider數據庫模式，然後編寫一個與該模式通信的定製提供程序。

最後的選擇是編寫一個自定義的MembershipProvider類。雖然這仍然是自己的，但它會強制你進入MembershipProvider的結構，這樣你就可以在以後換一個不同的（例如ActiveDirectoryMembershipProvider），並提供一個通用接口來與證書和登錄進行交互，例如可以輕鬆使用內置的登錄控件。

如果您已經在使用MembershipProvider並詢問是否存儲其他特定於用戶的數據，那麼我會建議SqlProfileProvider提供上面提到的有關SqlMembershipProvider的所有注意事項。 ProfileProvider提供了一個用於維護當前登錄用戶的特定用戶數據的結構。

欲瞭解更多信息：

• Introduction to Membership
• Implementing a MembershipProvider
• ASP.NET Profile Providers

Answer 2

您可以在會話中存儲一個對象，該對象包含所有必需的用戶信息。您只需要在控制器，視圖或其他您想要檢索用戶信息/配置文件的基類中添加一個屬性。這將是授權信息而不是任何驗證信息（例如表單驗證）

Answer 3

您也可以實現自定義標識。它們非常容易實現，並且它們允許您在Identity中存儲所需的任何用戶信息，然後將其存儲在Identity中放入的Cookie中，因此每次獲取該信息時都不會碰到數據庫。

只需創建一個從GenericIdentity繼承的新類，然後您就可以繼續使用了。

你當然必須小心，因爲它放在一個cookie裏面，你放了多少信息，但是在你談論的情況下，通常用戶相關的信息並不那麼大。

我們使用自定義標識來存儲關於用戶的信息的幾個位，並且它工作得很好。

Answer 4

你可以試試 「Windows標識基礎」。我已經在我的一個項目中使用了它一段時間了。它允許「基於聲明的身份驗證」，這基本上意味着您可以指定「聲明」，即在用戶登錄時描述用戶的信息串。

登錄後，可以從HttpContext.Current.User字段中讀取用戶的聲明。您還可以使用與角色身份驗證模式無縫集成的「角色」聲明;這意味着您可以爲用戶提供「經理」角色聲明，然後使用「if（User.IsInRole（」manager「））。

作爲額外的好處，WIF使得在其他應用程序中重新使用您的登錄屏幕變得非常容易。

總而言之，它非常靈活，但文檔非常差。我在StackOverflow上詢問並回答了許多關於「Windows Identity Foundation」的問題。

Answer 5

過去我們已經做了很多次了。與Thomas提到的類似，我們通常所做的是實現一個基於Microsoft SQL Memberhsip提供程序的新成員資格提供程序來執行此操作。我們從基礎的MembershipUser類繼承並添加我們想要在用戶對象上擁有的任何自定義屬性。您必須爲GetUser實現上的成員資格提供程序實現數據庫讀取，以便您可以將您需要的額外屬性合併到數據庫讀取中。

如果您使用的是SQL Server，Microsoft已經爲其發佈了2.0代碼。您可以在Scott Gu的博客中獲得更多信息。

http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx

如果你想從頭開始，他們也有很好的資源在MSDN。

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

和

http://msdn.microsoft.com/en-us/library/6tc47t75.aspx

一旦實現你的供應商，則可以將會員用戶添加到當前網絡環境的項目集合從您的代碼訪問它。基本用戶類的非擴展屬性也可以在正常的請求線程上使用。

隨着微軟發佈2.0版本的源代碼，我們發現它幫助我們減輕了一些關於重塑的擔憂。你的實現需要考慮的另一件事是基於你的場景，你可以繞過實現一些代碼。如果您正在訪問已擁有憑證信息的後端系統，則此示例爲CreateUser代碼。

Answer 6

您似乎對您的身份驗證過程相對滿意，但您希望探索會話/設置的其他選項。

我的建議只與設置有關（角色，首選項等）。）

在我看來，不得不遍歷從UI到Business層到DB層到DB的整個技術堆棧有時有點矯枉過正。 對於在會話期間不可能更改的數據，這會增加很多開銷......可能會發生多個數據轉換（DB（關係格式） - > ORM - > Web服務XML序列化 - > Web層反序列化）。

您可能會考慮一個不依賴於沉重的RDBMS系統或ASP.NET緩存/會話模型的會話系統。有很多選項非常高效，並且規模很好。

您可以使用Ayende Rahien的RavenDB（Built for .NET）。其主要目標是提供對無模式JSON文檔的低延遲，高性能訪問。

使用此解決方案，您可以在Web層中設置ravenDB，以便訪問數據的速度非常快。 第一次驗證和檢索設置時，您將在此會話數據庫中存儲用戶ID和設置信息。 之後每次加載控制器時，都可以訪問設置數據，而無需返回到RDBMS。 此數據庫也可用於緩存其他網絡相關數據。

至於安全性，無論您使用何種方法，設置數據都會將其設置到Web層。這個解決方案不會比其他選項更安全（比未加密的cookie更安全）。如果您需要，您可以加密會話數據 - 但這會再次增加您的開銷。

只是百萬選擇中的另一個考慮。

好運，

讓我們知道您的決定！

Patrick。