通用的系統權限模型的設計

• 通用的系統權限模型的設計
• • 基于角色的通路控制(RBAC)
  • “使用者-角色-權限”的授權模型
  • 有使用者組的模型
  • “使用者-角色-權限-資源”的授權模型
  • 寫在最後
• 權限模型建表SQL擷取

通用的系統權限模型的設計

一個系統的開發往往分成若幹個子產品，有些子產品跟業務相關，但是也有部分子產品是可複用的基礎子產品，比如權限管理子產品，一次做好，多次可以複用。本文将介紹部落客對權限管理子產品的一些總結。

基于角色的通路控制(RBAC)

常見的權限控制方式是基于角色的通路控制(RBAC)。

其基本思想是，對系統操作的各種權限不是直接授予具體的使用者，而是在使用者集合與權限集合之間建立一個角色集合。

每一種角色對應一組相應的權限。一旦使用者被配置設定了适當的角色後，該使用者就擁有此角色的所有操作權限。

這樣做的好處是，不必在每次建立使用者時都進行配置設定權限的操作，隻要配置設定使用者相應的角色即可，而且角色的權限變更比使用者的權限變更要少得多，這樣将簡化使用者的權限管理，減少系統的開銷。

“使用者-角色-權限”的授權模型

RBAC簡單地了解就是通過角色将使用者和權限關聯起來，一個使用者擁有多個角色，一個角色擁有多個權限，構成“使用者-角色-權限”的授權模型。在這種模型中，使用者與角色之間、角色與權限之間，通常都是多對多的關系。如下圖所示。

其中角色是若幹個權限的集合，比如說一個人力系統，有經理、員工、組長等不同角色，每個角色的權限不一定是一樣的，如果使用者A是經理，需要對員工的績效做評價，但評績效包括打分、做評價、檢視員工資訊等多個權限，一個個授權非常繁瑣，這個時候隻需要這些權限一次性授予經理這個角色，然後把經理的角色給使用者A即可。

有使用者組的模型

上面把若幹權限集合于角色授權給使用者，可以解決當一個人的權限過于多的時候繁瑣的添權重限，但是如果當同一個權限需要的使用者比較多的情況下，也存在這一問題。這個時候我們可以通過增加一個使用者組，每個使用者組内有若幹個使用者，我們隻需要将需要相同權限的使用者分到同一個使用者組，然後把擁有權限的角色分給使用者組即可，同理，我們對一些在大多數情況下會同時擁有的角色也來個角色組，像管理者，既有管理者角色的權限，也有普通使用者的權限。如下圖所示。

新增一個使用者組的表，将其與使用者表和權限表關聯起來，這樣一來，通過一次授權就可以給多個使用者授予相同的權限，這個時候使用者的權限就是使用者個人的權限和所在使用者組的權限之和。

“使用者-角色-權限-資源”的授權模型

權限的展現通常包括：

• 菜單的顯示和通路，比如不同角色使用者登入展示的菜單不一樣；
• 頁面元素的顯示和操作，比如一個頁面是兩個角色通用，但是其中一個角色不能增删改，隻允許檢視，那麼對這類角色就要單獨做限制，不顯示或者不能操作對應按鈕；
• 檔案的管理，很多系統都有通過操作檔案實作業務的批量操作，不同的角色對同一類檔案的操作也不一樣，有些可以修改，有些隻可以下載下傳。

是以，我們可以将權限再做細分，把菜單、頁面元素和檔案等拎出來，作為資源管理起來，而權限裡面就是對各類資源的具體操作，構成“使用者-角色-權限-資源”的授權模型。如下圖所示。

每一個資源與權限對應起來，這樣增加模型的維護性，當我們的系統有新的資源類型需要權限控制時，我們隻需要新增對應的資源表和與權限的關聯表即可。

各個資源表與權限的關聯表和權限表是一對一的關系，即每添加一條資源，就要同時往三個表添加資料。

最終完整的表模型如下所示。

寫在最後

以上隻是一個基礎的權限模型，但應該也可以滿足一些小型系統，更完整一點可以還應該增加記錄檔表、session、ip和mac記錄等，同時還可以根據系統的對應業務增加相應的内容，但這些都是細枝末節，需要的時候加上都行。

權限模型建表SQL擷取

關注下方公衆号，回複“權限模型”，即可擷取建表SQL。該公衆号将不定期分享一些小demo、小項目以及學習心得。

往期文章：

• Python爬取自己CSDN背景原始markdown資料
• 對外API接口的安全性設計及鑒權方式
• 基于FreeMarker的自定義代碼生成器
• vue實作markdown編輯器以及md檔案轉化成html
• 使用Java生成思維導圖
• Java實作簡易畫圖闆
• 用Java實作平衡二叉樹