C#許可權控制

前言：
許可權往往是一個極其複雜的問題，但也可簡單表述為這樣的邏輯運算式：判斷“Who對What(Which)進行How的操作”的邏輯運算式是否為真。針對不同的應用，需要根據項目的實際情況和具體架構，在維護性、靈活性、完整性等N多個方案之間比較權衡，選擇符合的方案。
目標：
直觀，因為系統最終會由終端使用者來維護，許可權分配的直觀和容易理解，顯得比較重要，系統不辭勞苦的實現了組的繼承，除了功能的必須，更主要的就是因為它足夠直觀。
簡單，包括概念數量上的簡單和意義上的簡單還有功能上的簡單。想用一個許可權系統解決所有的許可權問題是不現實的。設計中將常常變化的“定製”特點比較強的部分判斷為商務邏輯，而將常常相同的“通用”特點比較強的部分判斷為許可權邏輯就是基於這樣的思路。
擴充，採用可繼承在擴充上的困難。的Group概念在支援許可權以組方式定義的同時有效避免了重定義時
現狀：
對於在企業環境中的存取控制方法，一般有三種：
1.自主型存取控制方法。目前在我國的大多數的資訊系統中的存取控制模組中基本是藉助於自主型存取控制方法中的存取控制清單(ACLs)。
2.強制型存取控制方法。用於多層次安全層級的軍事應用。
3.角色型存取控制方法（RBAC）。是目前公認的解決大型企業的統一資源存取控制的有效方法。其顯著的兩大特徵是：1.減小授權管理的複雜性，降低管理開銷。2.靈活地支援企業的安全性原則，並對企業的變化有很大的伸縮性。
名詞：
粗粒度：表示類別級，即僅考慮對象的類別(the type of object)，不考慮對象的某個特
定執行個體。比如，使用者管理中，建立、刪除，對所有的使用者都一視同仁，並不區分操作的具體對象執行個體。
細粒度：表示執行個體級，即需要考慮具體對象的執行個體(the instance of object)，當然，細
粒度是在考慮粗粒度的物件類別之後才再考慮特定執行個體。比如，合約管理中，列表、刪除，需要區分該合約執行個體是否為目前使用者所建立。
原則：
許可權邏輯配合商務邏輯。即許可權系統以為商務邏輯提供服務為目標。相當多細粒度的許可權問題因其極其獨特而不具通用意義，它們也能被理解為是“商務邏輯”的一部分。比如，要求：“合約資源只能被它的建立者刪除，與建立者同組的使用者可以修改，所有的使用者能夠瀏覽”。這既可以認為是一個細粒度的許可權問題，也可以認為是一個商務邏輯問題。在這裡它是商務邏輯問題，在整個許可權系統的架構設計之中不予過多考慮。當然，許可權系統的架構也必須要能支援這樣的控制判斷。或者說，系統提供足夠多但不是完全的控制能力。即，設計原則歸結為：“系統只提供粗粒度的許可權，細粒度的許可權被認為是商務邏輯的職責”。
需要再次強調的是，這裡表述的許可權系統僅是一個“不完全”的許可權系統，即，它不提供所有關於許可權的問題的解決方案。它提供一個基礎，並解決那些具有“共性”的(或者說粗粒度的)部分。在這個基礎之上，根據“商務邏輯”的獨特許可權需求，編碼實現剩餘部分(或者說細粒度的)部分，才算完整。回到許可權的問題公式，通用的設計僅解決了Who+What+How 的問題，其他的許可權問題留給商務邏輯解決。
概念：
Who：許可權的擁用者或主體（Principal、User、Group、Role、Actor等等）
What：許可權針對的對象或資源（Resource、Class）。
How：具體的許可權（Privilege, 正向授權與負向授權）。
Role：是角色，擁有一定數量的許可權。
Operator：操作。表明對What的How 操作。
說明：
User：與 Role 相關，使用者僅僅是純粹的使用者，許可權是被分離出去了的。User是不能與 Privilege 直接相關的，User 要擁有對某種資源的許可權，必須通過Role去關聯。解決 Who 的問題。
Resource：就是系統的資源，比如部門新聞，文檔等各種可以被提供給使用者訪問的對象。資源可以反向包含自身，即樹狀結構，每一個資源節點可以與若干指定權限類別相關可定義是否將其許可權應用於子節點。
Privilege：是Resource Related的許可權。就是指，這個許可權是綁定在特定的資源執行個體上的。比如說部門新聞的發布許可權，叫做 "部門新聞發布許可權 "。這就表明，該Privilege是一個發布許可權，而且是針對部門新聞這種資源的一種發布許可權。Privilege是由Creator在做開發時就確定的。許可權，包括系統定義許可權和使用者自訂許可權使用者自訂許可權之間可以指定排斥和內含項目關聯性(如：讀取，修改，管理三個許可權，管理 許可權 包含 前兩種許可權)。Privilege 如 "刪除 " 是一個抽象的名詞，當它不與任何具體的 Object 或 Resource 綁定在一起時是沒有任何意義的。拿新聞發布來說，發布是一種許可權，但是只說發布它是毫無意義的。因為不知道發布可以操作的對象是什麼。只有當發布與新聞結合在一起時，才會產生真正的 Privilege。這就是 Privilege Instance。許可權系統根據需求的不同可以延伸生很多不同的版本。
Role：是粗粒度和細粒度(商務邏輯)的介面，一個基於粗粒度控制的許可權架構軟體，對外的介面應該是Role，具體業務實現可以直接繼承或拓展豐富Role的內容，Role不是如同User或Group的具體實體，它是介面概念，抽象的通稱。
Group：使用者組，許可權分配的單位與載體。許可權不考慮分配給特定的使用者。組可以包括組(以實現許可權的繼承)。組可以包含使用者，組內使用者繼承組的許可權。Group要實現繼承。即在建立時必須要指定該Group的Parent是什麼Group。在粗粒度控制上，可以認為，只要某使用者直接或者間接的屬於某個Group那麼它就具備這個Group的所有操作許可。細粒度控制上，在商務邏輯的判斷中，User僅應關注其直接屬於的Group，用來判斷是否“同組” 。Group是可繼承的，對於一個分級的許可權實現，某個Group通過“繼承”就已經直接獲得了其父Group所擁有的所有“許可權集合”，對這個Group而言，需要與許可權建立直接關聯的，僅是它比起其父Group需要“擴充”的那部分許可權。子群組繼承父組的所有許可權，規則來得更簡單，同時意味著管理更容易。為了更進一步實現許可權的繼承，最直接的就是在Group上引入“父子關係”。
User與Group是多對多的關係。即一個User可以屬於多個Group之中，一個Group可以包括多個User。子Group與父Group是多對一的關係。Operator某種意義上類似於Resource + Privilege概念，但這裡的Resource僅包括Resource Type不表示Resource Instance。Group 可以直接映射組織圖，Role 可以直接映射組織圖中的業務角色，比較直觀，而且也足夠靈活。Role對系統的貢獻實質上就是提供了一個比較粗顆粒的分配單位。
Group與Operator是多對多的關係。各概念的關係圖示如下：
解釋：
Operator的定義包括了Resource Type和Method概念。即，What和How的概念。之所以將What和How綁定在一起作為一個Operator概念而不是分開建模再建立關聯，這是因為很多的How對於某What才有意義。比如，發佈動作對新聞對象才有意義，對使用者物件則沒有意義。
How本身的意義也有所不同，具體來說，對於每一個What可以定義N種操作。比如，對於合約這類對象，可以定義建立操作、提交操作、檢查衝突操作等。可以認為，How概念對應於每一個商業方法。其中，與具體使用者身份相關的操作既可以定義在操作的商務邏輯之中，也可以定義在操作層級。比如，建立者的瀏覽視圖與普通使用者的瀏覽視圖要求內容不同。既可以在外部定義兩個操作方法，也可以在一個操作方法的內部根據具體邏輯進行處理。具體應用哪一種方式應依據實際情況進行處理。
這樣的架構，應能在易於理解和管理的情況下，滿足絕大部分粗粒度許可權控制的功能需要。但是除了粗粒度許可權，系統中必然還會包括無數對具體Instance的細粒度許可權。這些問題，被留給商務邏輯來解決，這樣的考慮基於以下兩點：
一方面，細粒度的許可權判斷必須要在資源上建模許可權分配的支援資訊才可能得以實現。比如，如果要求建立者和普通使用者看到不同的資訊內容，那麼，資源本身應該有其建立者的資訊。另一方面，細粒度的許可權常常具有相當大的商務邏輯相關性。對不同的商務邏輯，常常意味著完全不同的許可權判定原則和策略。相比之下，粗粒度的許可權更具通用性，將其實現為一個架構，更有重用價值；而將細粒度的許可權判斷實現為一個架構層級的東西就顯得繁瑣，而且不是那麼的有必要，用定製的代碼來實現就更簡潔，更靈活。
所以細粒度控制應該在底層解決，Resource在執行個體化的時候，必需指定Owner和GroupPrivilege在對Resource進行操作時也必然會確定約束類型：究竟是OwnerOK還是GroupOK還是AllOK。Group應和Role嚴格分離User和Group是多對多的關係，Group只用於對使用者分類，不包含任何Role的意義；Role只授予User，而不是Group。如果使用者需要還沒有的多種Privilege的組合，必須新增Role。Privilege必須能夠訪問Resource，同時帶User參數，這樣許可權控制就完備了。