前言：

權限往往是一個極其復雜的問題，但也可簡單表述為這樣的邏輯表達式：判斷“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上引入“父子關系”。