文章從權限模型出發，結合具體案例分享了To B 的權限體系設計關鍵環節和需要注意的問題，與大家分享。

背景

之前在另一篇文章里介紹了權限體系的基礎概念如RBCA和ACL，網友反饋說不夠深入，需要來點見真章的東東，最好是能夠看完后，就可以直接拿到工作中投入使用的。聯想到工作中遇到的幾個都屬于ToB領域里，但面向不同業務方向和類型的實際項目，拿來具體討論一下，如何為平臺設計一個比較通用的權限系統。

原型圖

我這里用的是xiaopiu，在線繪圖。不用額外安裝程序。如果專業點的，一般會用axure，有一定的學習門檻。

從這張原型圖里，可以看到這是一個體現了權限體系核心功能的簡單系統。

• 當王經理登錄的時候，不僅能管理系統概況，也能管理具體的實用功能也就是圍欄和視頻系統。
• 當巡邏員小李和巡邏員小明登錄的時候，他們只能管理圍欄和視頻系統。
• 通過賬戶和角色的組合，就能夠實現上面的要求

實現的原理是什么吶？首先來了解下資源的概念

背后的事兒

什么是資源

如果沒有【賬戶】和【角色】，這就變成了一個最純粹的功能系統了。這個系統由系統概覽和實用功能兩個一級菜單，以及下層的各個細分功能組成。

第一步需要用標識，來標記這些功能。通俗的，可以將這些功能命名為資源，后臺數據庫中就是通過資源ID來識別某一個具體的功能的。

頁面上的每個元素都要有對應的資源ID，這是為了在前端展示的時候，能夠做到讓不同用戶登錄后，有的用戶可以查看，有的可以編輯，有的可以刪除。

所以第二步，需要定義對各個資源ID能夠進行的操作，也就是資源和操作之間會產生一個映射關系。

資源和操作

操作的含義，可以理解為CRUD(創建Create/讀取Read/更新Upate/刪除Delete)四種類型。一般實際實現過程中，為了不這么麻煩，可以將這四種操作簡化為全有或者全無。用映射關系來表示就是

resourceId -> CRUD

實際實現的效果就是，當用戶能夠看到這個資源，那他就可以操作這個資源。如果真的遇到了有特定的需求，就是對于同一個資源，這一種類型的用戶必須有而且只能有查看的權限，同時必須沒有編輯的權限，那么就需要將這個映射關系打散為如下格式

resourceId -> R

resourceId -> CUD

接下來，準備工作都做好了。鐺鐺鐺，將進入重頭戲，賬戶和角色。

角色

從業務流程上來講，是先有角色，再有賬戶。所以需要先創建一個角色。

王經理是一個賬戶，他有一個叫做“經理”的角色。系統中新增一個角色的時候，一般至少有3個字段，分別是角色的名稱（必填），角色擁有的資源的權限（必填），對于該角色的描述（可選）。對于各項的要求如下：

• 角色的名稱不允許重復，如果有多個同樣名稱的角色，被賦予的權限還不一樣，系統就亂套了。
• 對應的資源權限。也就是上面提到的resourceId+CRUD的組合。當然支持多選。也就是同一個角色，可以擁有對多個資源的權限

根據上述描述，在系統中創建兩個角色

• 經理角色。具有對資源【系統概覽】和【實用功能】【圍欄】【視頻】的權限。這里要特別提一下，雖然將實用功能和圍欄分成兩個資源提了，但是實際操作時，當選擇了圍欄功能時，由于它是實用功能的子節點，默認直接將實用功能的權限也給這個角色就可以了，既簡單又不會造成更復雜的情況
• 巡邏員角色。具有對【實用功能】【圍欄】【視頻】的權限

賬戶

萬事俱備，只欠東風。最后一步就是新建3個帳戶。賬戶新建的時候，需要填寫的字段，除了賬戶名稱（當然賬戶名稱也是不允許的重復的）和本身這個系統要求的一些信息（例如照片，手機號，電話號碼等）以外，就只需要一個字段【角色】了。

這里的角色字段的取值，來自于上一小節里提到的【角色】。一個賬戶，可以綁定多個角色。不同的賬戶，也可以綁定同一個角色。

為了讓王經理，小李，小明能夠正常服務于自己的崗位，實際上就是：

• 新建一個賬戶，王經理，綁定的是之前創建好的 經理角色。
• 新建一個賬戶，小李，綁定的之前創建好的 巡邏員角色
• 新建一個賬戶，小明，綁定的之前創建好的 巡邏員角色

然后這三個人，用自己的帳號密碼登錄就可以了

總結

在一個真實的系統中，進行權限操作步驟是：

• 第一步定義自己系統的資源權限映射關系，權限是由資源+操作組成的
• 第二步創建角色，這個過程會將角色和對應的資源權限綁定
• 第三步創建帳號，這個過程會將角色和帳號進行綁定

另外，映射關系為

• 資源和操作：多對多
• 角色和權限：多對多
• 帳號和角色：多對多

本文由 @花生草 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。