RBAC：權限模型的初步理解

  近來部門接到一個外包項目，是基於現有的系統作一個知識文檔庫，相似於百度網盤同樣的功能，只是在角色和權限上與網盤不一樣，這個項目咱們部門稱爲KM，Knowledge Manager ，難點就在於文件的權限管理。

  如下是與權限相關的一些功能點：

• KM 有五類角色：KM 企業管理員， KM 部門管理員 ，KM團隊管理員 ，KM團隊成員 ， KM成員，權限依次遞減

• KM 有三個實體 ： 網盤、文件夾、文件

• KM 網盤的類型有：部門網盤，團隊網盤，我的網盤

• KM 文件夾的操做：建立、修改、刪除、移動、分享、受權

• KM 文件的操做：建立、修改、刪除、移動、分享、受權

歸根到底有兩點：

1. 不一樣角色對不一樣實體的操做有不同的權限

2. 高級別的角色能夠改變低級別的角色對指定實體的操做權限

  我本身出來工做已經兩年，計劃五年內成爲一名架構師，雖然此次不須要我對系統進行設計，可是我確定不會放棄此次機會，在上級出方案以前，我足足把需求文檔看了四遍，去想如何才能設計一個好的架構進行開發，不過，最後的結果仍是打擊到我了，實在沒想到還有如此簡單的方法。全文分解爲兩部分：

• 我本身的設計：策略模式

• 上級的設計：RBAC權限模型

策略模式

  開始的想法是，架構必然和設計模式有關，考慮到實體執行的操做類型如上文所說基本有六種操做，結合五類角色，正好能夠採用策略模式，基本的思路以下：

• 獲取用戶信息，基於不一樣網盤、文件夾、文件，實現對應的角色

• 根據角色，判斷對應的操做是否具相應的權限

• 若不知足權限，則查詢權限表，判斷高級角色是否受權

• 最終返回是否具有權限的數據，以供前端進行響應式回顯

  這就是我最開始的思路，其實想到這套方案，內心仍是挺開心的，緣由在於：

• 用到了策略模式，剛學就能用上

• 解耦，之後不一樣角色對不一樣實體的操做的維護難度大大下降

• 不須要頻繁的查詢數據庫，畢竟有一部分業務邏輯是不須要經過查詢數據庫的，相似於KM 企業管理員，權限最大，對任何實體都具有操做權限

  然而當我把想法在早會上提出來時，上級告訴我說，現行有一種很成熟的權限模型：RBAC權限模型，他的設計可以解決這個項目大部分的需求。方案不被採納當然有一點小失落，可是，我卻看到了一個很厲害的模型，足以讓我漲見識，之後遇到權限管理的時候，首先應該想到RBAC模型，結合項目的需求，對模型進行擴展。

RBAC權限模型

• 基本概念

  • 基於角色的權限訪問控制（Role-Based Access Control）

  • 權限受權其實是Who、What、How的關係，三者構成了訪問權限三元組,也就是「Who對What(Which)進行How的操做

• 支持三個著名的安全原則

  • 最小權限原則

  • 責任分離原則

  • 數據抽象原則

• 類圖
  

• 數據庫表：
  

• 我的理解

  • 經過給角色受權，而後將附有權利的角色施加到某個用戶身上，這樣用戶就能夠實施相應的權利

  • 經過中間角色的身份，是權限管理更加靈活：角色的權利能夠靈活改變，用戶的角色的身份能夠隨着場所的不一樣而發生改變

  • 這樣這套RBAC就幾乎能夠運用到全部的權限管理的模塊上

---

  RBAC在使用的過程，被不斷地改進，進一步研發出更成熟的模型，如下的模型則是基於基本模型進行擴展：

• RBAC1 ：基於RBAC0模型，進行了角色的分層，也就是說角色上有了上下級的區別，存在了繼承包含關係，也就是前邊說過的適合於用樹展示的哪一種自關聯的結構，這種模型合適於層次明確，包含明確的角色關係

  • 類圖
    

• RBAC2 ：基於RBAC0模型的基礎上，進行了角色的訪問控制。

  • RBAC2中的一個基本限制時互斥角色的限制，互斥角色是指各自權限互相制約的兩個角色，對於這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時得到兩個角色的使用權

  • 角色的權利權利是有限的，用戶有用的角色也是有限的，固然分配用戶時也是有限的，不能進行無限制的分配用戶

  • 要想得到較高的權限，要首先擁有低一級的權限

  • 類圖
    

• RBAC3 : 最全面級的權限管理，基於RBAC0的基礎上，將RBAC1和RBAC2進行整合了，最全面，也最複雜

  • 類圖
    

---

  任何的權限控制均可以基於 RBAC權限 進行擴展和實現，成熟的開發模型就能爲開發者帶來足夠的便利，也很佩服勤勞、勇敢、智慧的工程師，可以設計出如此出彩的模型。  此次也深入地意識到本身知識面的不足，本身閉門造車確定會與這個社會脫節，與此同時，學習速度太慢，不會使用搜索引擎去找答案，也會被這個社會淘汰。謹記。