權限系統提的最多的就是 RBAC（基於角色的訪問控制）。 所謂角色，其實就是權限的集合，某個角色就是某幾個權限的結合。其目的是為了簡化授權和鑒權的過程。
基於角色的權限控制用在簡單的權限環境下沒有問題，如果在權限控制比較復雜的系統中，或者說要做通用的權限系統時，基於角色的權限控制會帶來以下問題：
角色可以用來做功能權限，做數據權限的話，會導致角色數量非常多 比如：bug管理系統，一般有 developer, reporter, manager 等一些角色，其中，reporter 可以創建bug，developer 可以解決，回復bug，manager 可以統計bug 等等。 在這個系統中，通過設置 developer，reporter，manager 幾個角色，可以使得授權，鑒權更加簡單，直觀。 但是，如果權限粒度要求更細的話，比如，某些reporter只能創建普通級別的bug，某些reporter可以創建各個級別的bug，或者有更加細粒度的權限要求的話，角色的數量就會激增。 到時候，管理角色本身帶來的工作量反而會大於角色帶來的好處。
角色是一維的，不同的角色之間一般都是獨立的，而人員之間一般有樹狀的組織關系。所以，角色就很難與已有的組織關系互相映射。 而授權的時候，經常是上級的組織會自動獲取下級創建的數據的一些權限
對於不確定的系統來說，角色不好定義。如果是bug系統，比較成熟，方便定義角色類型，如果是通用系統的話，用戶其實不太容易定義好自己需要的角色。
基於角色的權限系統一般簡稱 RBAC，而這裡的 RBAC 是指 基於資源的權限系統。
目的是設計一種通用的權限管理系統，不和任何的實際的業務關聯，只做權限相關的管理和驗證。 之所以以 資源 為核心，是因為上面的提到的那些基於 角色 的限制。 基於資源的權限系統是圍繞 組織樹 和 資源樹 來進行權限的。
權限系統本身提供一個超級用戶(admin)，通過此用戶來初始化最初需要的信息。
初始信息只需要定義：
有了以上信息，就完成了針對某個系統和組織的權限系統的基本初始化。 基本信息初始化之後，可以導入組織/人員，以及資源信息，或者直接在權限系統提供的頁面上操作。
注意 每個資源只有一個父節點，每個組織也只有一個父組織，但是每個人員可以屬於多個組織。
授權是權限系統中重要的步驟之一，另一個重要步驟就是鑒權。 授權有2種視圖：
人員/組織 視圖 下的授權流程
注1 前2步的選擇都可以多選。
資源 視圖 下的授權流程
鑒權是使用最頻繁的步驟，幾乎每次請求都會有鑒權的操作。 鑒權就是判斷 某人對某資源做某個動作 是否合法，所以鑒權的 input 是 人員/組織，資源，動作； output 則是是否鑒權成功。
對功能權限來說，一般數據量不會太大，即使沒有自動授權，手動授權也可以完成。 但是對數據權限來說，不僅數據量龐大，而且如何授權也不確定，數據的變化也可能會很頻繁，手動來做幾乎不可能。
自動授權目的是將自動授權機制參數化，讓用戶通過設置不同的參數來生成不同的權限數據。 自動授權機制是以插件的形式加入到權限系統中的，默認可以提供幾種常用的自動授權機制插件。 在授權時，也可以指定使用一種或者多種自動授權插件。
下面以一個示例來說明插件是如何使用的。 示例插件：創建數據時自動授權插件 功能：用戶A 創建數據X 後，生成如下權限數據：
此插件參數就是3個list：自己的動作列表，同組織成員的動作列表，其他組織人員的動作列表 插件的參數是在權限系統中的插件管理功能中配置的（插件參數的設置需要用到動態表單，因為插件的參數個數，類型等都是不定的）
使用流程如下：
針對不同類型的系統，授權方式千差萬別，將授權的實現剝離出來，是為了增加系統的通用性。
通用權限管理的主要的功能就是 授權 和 鑒權 ，其本質都是對權限數據（什麼人對什麼資源可以做什麼動作）的管理。 授權的難點在於給某人授與某個數據的權限之後，組織中其他關聯人員可以計算出自己對這個數據的權限，這就是自動授權插件的意義。 鑒權的難點一是權限的數據量會比較大（如果權限粒度細的話），一是有些權限是需要計算的。
基於角色的權限系統的核心在 角色（人員），而基於資源的權限系統核心在 資源，資源是權限系統需要保護的東西。 希望能從資源的角度來設計出更加通用的權限管理系統。