學習目標：
理解RBAC模型的基本概念及設計思路
了解SAAS-HRM中權限控制的需求及表結構分析
完成組織機構的基本CRUD操作
完成用戶管理的基本CRUD操作
完成角色管理的基本CRUD操作
1 RBAC模型
1.1 什么是RBAC
RBAC（全稱：Role-Based Access Control）基于角色的權限訪問控制，作為傳統(tǒng)訪問控制（自主訪問，強制訪問）的有前景的代替受到廣泛的關注。在RBAC中，權限與角色相關聯(lián)，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創(chuàng)造，用戶則依據(jù)它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統(tǒng)的合并而賦予新的權限，而權限也可根據(jù)需要而從某角色中回收。角色與角色的關系可以建立起來以囊括更廣泛的客觀情況。
訪問控制是針對越權使用資源的防御措施，目的是為了限制訪問主體（如用戶等）對訪問客體（如數(shù)據(jù)庫資源等）的訪問權限。企業(yè)環(huán)境中的訪問控制策略大部分都采用基于角色的訪問控制（RBAC）模型，是目前公認的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法
1.2 基于RBAC的設計思路
基于角色的訪問控制基本原理是在用戶和訪問權限之間加入角色這一層，實現(xiàn)用戶和權限的分離，用戶只有通過激活角色才能獲得訪問權限。通過角色對權限分組，大大簡化了用戶權限分配表，間接地實現(xiàn)了對用戶的分組，提高了權限的分配效率。且加入角色層后，訪問控制機制更接近真實世界中的職業(yè)分配，便于權限管理。
在RBAC模型中，角色是系統(tǒng)根據(jù)管理中相對穩(wěn)定的職權和責任來劃分，每種角色可以完成一定的職能。用戶通過飾演不同的角色獲得角色所擁有的權限，一旦某個用戶成為某角色的成員，則此用戶可以完成該角色所具有的職能。通過將權限指定給角色而不是用戶，在權限分派上提供了極大的靈活性和極細的權限指定粒度。
1.3 表結構分析
一個用戶擁有若干角色，每一個角色擁有若干權限。這樣，就構造成“用戶-角色-權限”的授權模型。在這種模型中，用戶與角色之間，角色與權限之間，一般者是多對多的關系。
2 SAAS-HRM中的權限設計
2.1 需求分析
2.1.1 SaaS平臺用戶設計
一般SaaS平臺基本角色由平臺管理員、租戶用戶、租戶管理員、租戶其他角色組成。以O2O業(yè)務的企業(yè)架構為例，圖解系統(tǒng)角色關系。
平臺管理員：負責平臺的日常維護和管理，包括用戶日志的管理、租戶賬號審核、租戶狀態(tài)管理、租戶費用的管理，租戶權限的管理，要注意的是平臺管理員不能對租戶的具體業(yè)務進行管理。如果租戶數(shù)量大，還可以對平臺管理員劃分角色，可以按地域劃分，比如西北地區(qū)、東北地區(qū)等，讓平臺管理員分別管理不同的租戶；也可以根據(jù)業(yè)務進行劃分，比如租戶管理員，租費管理員等。
租戶：指訪問SaaS平臺的用戶企業(yè)，在SaaS平臺中各租戶之間信息是獨立的。租戶信息包括租戶的名稱、地址等租戶企業(yè)的相關信息，主要用來區(qū)別各租戶，并且由平臺管理員對租戶賬號狀態(tài)進行管理。各租戶可根據(jù)需要自行選擇SaaS平臺功能模塊并依此付費。
租戶管理員：為租戶角色分配權限和相關系統(tǒng)管理、維護。
租戶用戶：根據(jù)租戶管理員分配的權限以及自己的角色進行相關的業(yè)務管理。各租戶用戶只能訪問該租戶選擇的 SaaS 平臺的功能模塊。一個系統(tǒng)用戶如果有多個角色，則他只能看到當前角色下的數(shù)據(jù)，通過角色切換，可以達到查看所屬其他角色下的數(shù)據(jù)信息。
租戶角色：根據(jù)業(yè)務功能分由租戶管理員進行角色劃分，劃分好角色后，租戶管理員可以對相應的角色進行權限分配。角色有上下級關系，上級可以查看下級的數(shù)據(jù)，下級不能訪問上級的數(shù)據(jù)，平級之間不能相互訪問。角色上層可再加入分組層（如分部門或團隊等），不同組別的數(shù)據(jù)范圍不同，資源、操作可以共享也可以隔離。
2.1.2 需求分析
在應用系統(tǒng)中，權限是以什么樣的形式展現(xiàn)出來的？對菜單的訪問，頁面上按鈕的可見性，后端接口的控制，都要進行充分考慮
-
前端
前端菜單：根據(jù)是否有請求菜單權限進行動態(tài)加載
按鈕：根據(jù)是否具有此權限點進行顯示/隱藏的控制 -
后端
前端發(fā)送請求到后端接口，有必要對接口的訪問進行權限的驗證
3.2 權限設計
針對這樣的需求，在有些設計中可以將菜單，按鈕，后端API請求等作為資源，這樣就構成了基于RBAC的另一種授權模型（用戶-角色-權限-資源）。在SAAS-HRM系統(tǒng)的權限設計中我們就是才用了此方案
針對此種權限模型，其中權限究竟是屬于菜單，按鈕，還是API的權限呢？那就需要在設計數(shù)據(jù)庫權限表的時候添加類型加以區(qū)分（如權限類型： 1為菜單 2為功能 3為API）。
2.2 表結構分析
這里要注意的是，權限表與權限菜單表、頁面元素表與API接口表都是一對一的關系
與傳統(tǒng)的RBAC模型對比不難發(fā)現(xiàn)此種設計的好處：
- 不需要區(qū)分哪些是操作，哪些是資源
- 方便擴展，當系統(tǒng)要對新的東西進行權限控制時，我只需要建立一個新的資源表，并確定這類權限的權限類型標識即可。
