ASP.NET會員和基於角色的安全

我發展與ASP.NET & C#一個博客引擎。主要解決方案包括幾個項目的下面所列ASP.NET會員和基於角色的安全

DomainModel：域實體和接口庫
AppService：應用服務，視圖模型映射器，消息等
Repositories：EF庫，XML庫，存根庫
Presentation：實現MVP模式（視圖，主持人，接口）

現在，用戶端項目是一個WebForms Web應用程序，並且該項目即將完成。最後一件事是整個系統與ASP.NET Membership。有兩件事情需要考慮。

首先，只有一個用戶帳戶ID從在博客數據庫中的成員數據庫所需。最後，基於角色的安全性必須在UI項目中實施。因爲即時通訊還挺新的分佈式應用程序的開發，DDD之類的東西，我想知道如果基於角色的安全性的實現是UI的應用程序僅僅只是責任，或有在其他層以照顧其他的事情解決方案。據我所知，只有視圖（網頁）必須實現基於角色的安全性並呈現不同的內容，並根據當前會話提供不同的功能。但是，這一切？

我知道這可能是一個通用的問題，會有所不同根據項目需求的過程中，實現和設計。但是如果在分佈式/分層應用程序中實現基於角色的安全性和表單身份驗證時遵循一般的經驗規則，那麼事先了解它們將非常棒。例如：

安全性實現僅僅是UI應用程序的責任。
我可以調整/更改我的域模型和/或其他圖層的設計，以便基於角色的安全性的實現更容易，而不會完全落在UI應用程序上。
是否採取安全考慮其他層，從而使UI層將數據只是一種表象，並在用戶和系統之間的媒介是一個好主意。

這三個問題似乎是相同的（杜）。

如果這是一個重複或偏離主題的問題，那麼生病會被鏈接，引用和評論幫助。但如果沒有，我想這是一個徹底的話題。 TNX

來源

2011-08-25 Nexus

安全應該是所有應用程序的責任。這真的取決於您的應用程序的結構。

我認爲所有層級都應該有一些參與。安全應該是其他服務可以使用的另一種服務。這樣你就可以在各個級別訪問安全模型。如果用戶未被授權，管理用戶界面可以立即阻止用戶，但可以說數據檢索服務可以檢查它檢索的對象對當前用戶有效。

如果您想以其他方式使用您的數據模型，例如通過Web服務或其他應用程序（例如Silverlight），您也可以獲得優勢。

更新

所有層級真的需要知道安全的，因爲所有層需要在某一時刻去觸摸它。用戶界面需要它，因此它可以切換UI元素的開啓和關閉。服務需要注意它，以確保它們正在執行的操作對當前用戶有效等等。

安全真的不應該是你想到的項目結束&只是打開。它應該是各級應用程序設計的東西。

你如何實現它取決於你如何編寫你的應用程序。我會說最好的方法是在你的應用程序的asp成員資格之間建立一個抽象層。您可以獲得所有您已知的好處，例如測試，重新設計等。

您可能想要考慮的一件事是權限或權限的概念。 ASP沒有處理這個問題的本地庫，所以你不得不推出自己的。任何時候你想做點什麼，都要檢查用戶是否有權利。這些權限可以分配給角色，而角色又可以分配給用戶或用戶組。您可以對用戶可以執行的操作進行細化控制，這使得將來可以輕鬆添加新角色。

來源

2011-08-25 14:27:44

只是爲了確保我明白這個權利，如果安全可以另一個服務，那麼只有我的'AppService'層需要引用和使用這個服務層，對吧？還可以提供樣本/鏈接或者多談一些關於如何編寫這樣的安全服務以便其他層可以使用它的內容。最後，如果安全性要在另一個服務層實現，那麼MVP模式和我的Web表單應該如何與此服務層集成？ – Nexus

安全是一個貫穿始終的問題：涉及到UI，應用程序和領域層。我的理解是，你處理像「只有作者可以編輯博客」或「只有註冊用戶可以評論」的規則。在這種情況下，用戶界面應該瞭解這些規則，以決定是渲染「編輯」還是「評論」鏈接。域對象應該能夠執行這些規則。

據我所知，ASP.NET Membership做了很多事情，包括用戶存儲，認證，授權和角色管理。但它不知道你的域名。它不知道博客是什麼。它知道ASP頁面是什麼。因此，如果您不想將域規則表達爲頁面訪問規則，則可能需要在應用程序和ASP.NET成員資格之間劃一條粗線。您可能希望將用戶存儲和身份驗證委派給ASP.NET，但您自己完成其他任務。在您的域模塊中不要直接依賴ASP.NET也可能是一個好主意。如果您稍後決定從Web窗體切換到MVC，或者您的博客引擎將具有Web API，則還需要考慮ASP.NET Membership如何工作。

來源

2011-08-25 15:23:51 Dmitry

不確定你到底在幹什麼，但值得注意的是，標準PrincipalPermissionAttribute Class可以很好地適用於使用此提供者技術實現的ASP.NET角色。

這意味着您可以使用代碼訪問安全性和聲明性屬性來確保您的API /域/方法只能由特定角色的用戶訪問。所以是的，你可以使用ASP.NET Membership強制UI層以外的安全性。

來源

2011-08-25 16:28:17

在UI應用程序中實現安全性會不會更容易，所以未經授權的調用將無法達到其他層？我的理解是，它應該更容易這樣，但如果這種類型的安全可以在UI應用程序被覆蓋然後是，其他層就必須瞭解一些安全規則以及 – Nexus

@Nexus [？] - 其實，你可以做兩個。您可以在您的域/業務層添加屬性，也可以在UI層中使用它。這取決於您需要的安全級別。在「容易」這個詞通常不適合以「更安全」 :-) –

這樣的'域對象和其他層的方法代碼訪問安全attributes'組合，並呈現在用戶界面層不同的內容，將工作的能力精細。順便說一句西蒙，是否是一個好主意，檢查當前會話是否在每個方法/服務的「AppService」層中是「authenticated/authorized」？這可以在另一個服務層的幫助下完成。畢竟，AppService層是整個系統的入口點，用戶只會與這個層進行交互。 – Nexus

解決這個問題一段時間後，我得出了下面的結論。

執行安全性如Authentication,Role-based security,Authorization等在用戶體驗層不是主要有兩個原因一個好主意：

如果你想爲你的應用程序創建其他UI，說WinForms或Silverlight UI，那麼你就要有落實這種安全從頭開始。
您可以隨時使用系統的其他組件/圖層而無需創建UI應用程序。假設您創建了一個引用系統中其他圖層的簡單控制檯應用程序（即Repositories）。那麼你可以實例化一個存儲庫並處理數據。在這種情況下，您已成功覆蓋任何安全性。

因此，解決方案是在另一個嵌入域模型本身的層中實現這種有點安全性，而不是綁定到用戶體驗層（UI）。

現在有一些變化，你可能會如何去做這件事。假設我們有一個名爲AppService的層，它是整個系統的入口點。該層由消息（消息模式如Request-Response模式），ViewModels組成，這些消息是域實體的扁平視圖，以及Methods for retrieving and manipulating data等。在此，我們可以在PrincipalPermission對象的幫助下實施此類安全措施。我們可以將安全規則應用於類和方法。這裏有一個簡單的例子：

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)] 
public void DoSomething() 
{ }

隨着對這種方法定義的屬性，代碼要求要認證的呼叫者。認證模型可以是任何東西，包括Windows Authentication,Forms Authentication等等。現在這個工作正常，因爲現在我們已經從服務層中定義的安全規則鬆散地耦合了UI。但是仍然有一個問題。

只要服務層確實是主入口點到系統，此設計將工作正常。這意味着如果您仍然可以實例化一個存儲庫，例如而不需要需要獲取AppService的實例，那麼您仍可以覆蓋安全規則。即要麼你必須以這種方式設計你的領域模型，與你的系統的組件/層一起工作將需要一個AppService的實例。在這種情況下，系統中提供的任何功能只能通過應用程序服務層訪問。另一方面，如果這是不可能的，或者目前沒有擔心，那麼您還必須在其他層中定義安全規則。這意味着你將不得不在存儲庫中定義安全規則。因此如果有人實例化存儲庫並試圖操縱數據，而不通過UI或AppService層執行他的命令，則仍然執行安全措施。

另一件事是在您的類和方法上使用PrincipalPermission規則不會綁定到特定的認證/授權模型。所以你可以在帶有Forms Authentication的web應用程序中使用這樣的安全規則，或者使用帶有Windows/AcctiveDirectory Authentication等的windows應用程序。

正如你還記得我正在開發一個簡單的博客引擎ASP.NET和這個模型工作正常。如果有更詳細的深入優點和缺點，或樣本和博客文章，可以幫助這個主題，請務必發表您的意見和答案[：

來源

2011-09-02 15:30:00 Nexus

ASP.NET會員和基於角色的安全

回答

相關問題