文章從權限模型和概念出發，對權限系統的核心進行剖析，抽象出權限系統中的核心要素，并結合案例對權限系統進行介紹。

一個最簡單表達了權限模型的實例

小明和小李，分別用自己的帳號和密碼登錄了同一個平臺頁面。小明登陸上去后，可以看到小說和視頻頁面。小李登陸上去之后，只能看到小說頁面。

emmm…..他倆有不同的權限。

后臺是什么樣的模型來實現的呢。對于ToB領域的權限控制，產品經理經常用到的是RBAC模型

什么是RBAC

RBCA是英文role-based access control的縮寫，即基于角色的權限管理系統，用來實現對用戶授權，訪問系統的特定部分，實現不同粒度的權限控制?？梢岳斫鉃橐环N非功能性的需求，而是一種安全機制。據說一般一個企業超過500名員工，都會需要用到權限控制。至于“安全”這個主題，在對企業打分的時候，不一定會成為一個加分項，但一定可以成為一個扣分項。

RBAC的核心是角色（role）。所有使用者的能夠操作的內容，都是通過角色來進行賦予和禁止，而不是直接通過對使用者本身來繼續賦予和禁止。如軟件行業的行話，當一個系統太復雜了，那么就為他加一個層吧。同理，這樣一個role層加入是為了簡化復雜度。具體原因可以看RBAC和ACL的區別

下面來看一下，如果用戶要執行一項操作，需要滿足的RBAC的繞口令似的3原則

1. 角色分配：一個用戶必須被分配一個角色
2. 角色授權：當前角色必須被授權給當前用戶
3. 權限授權：權限必須被授予給當前用戶的角色，當前用戶才能執行這項權限

RBAC和ACL的區別

傳統的ACL是屬于更底層更基礎的數據對象的權限控制，比如一個文件可以讀寫的權限控制。RBAC是帶有業務含義的權限控制。比如可以表達出銀行業里，保險箱需要的開啟需要銀行經理和儲戶的鑰匙同時存在。又比如可以表達出業務流程中不能出現“自己審理自己”的這種荒唐現象。

權限體系與帳號體系的關系

賬號體系包含的內容是用戶帳號的注冊/登錄/密碼修改/密碼找回功能。其中用戶帳號登錄，就會需要權限系統提供的功能來進行協助校驗。

校驗內容包含：

1. 這個用戶是不是被禁止，是否可以登錄系統。
2. 這個用戶登錄后，能夠看到哪些頁面
3. 在他能夠訪問到的頁面上，能夠執行哪些操作

權限體系與組織架構的關系

組織架構是企業的行政組織架構。企業所使用的系統，都是其組織結構的反應。所以任何一個ToB的系統，如果要獲得客戶的認可，必須符合客戶的組織結構。

大型企業的組織架構會相當復雜，比如國家電網這種重量級選手，有職能部門，地區分部，一級省公司，直屬單位，再往下細分那就更多更復雜了。如果小型公司，可能就只有公司總體和部門兩個級別，比較簡單?？梢韵胍?，對于越復雜的組織結構，所要求的權限控制的精細度，權限限制會更加復雜

權限體系與組織架構能夠一眼所見的，最直接的關系，就是數據。組織與組織之間的數據，應該是隔離的，組織A的人員，不能夠去訪問和操作其他組織的數據。這些需要通過權限體系來實現。

簡單權限系統的設計

如前所述，首先需要設計的是角色。

1. 角色分離

一般角色可以按照兩種維度進行分離，管理的維度和業務的維度。

1. 管理角色：一般是企業的運維人員，可以登錄系統，進行維護和授權操作。一般通過自定義的方式，可以支持頁面上新建。一般一個賬號可以同時有多個自定義角色
2. 業務角色：按照職責進行確認，比如財務，保潔員，總經理等。一般通過內置角色的方式來實現，不支持頁面上新建。一般一個帳號可以有一個內置角色

上面說的是一般，一般，一般。當然實際情況中總會有新的不同情況

管理角色會發生變化，但是業務角色由于和企業的組織架構，職級，職能相綁定，一般創建好之后是不會發生變化的。

2. 用戶分配角色

參考RBAC三原則，當系統中新建一個用戶時，必須為這個用戶分配一個對應的角色

3. 角色授權

不管是內置角色還是自定義角色，當新建一個角色時，需要為這個角色進行授權。permission是一個操作，定義了能夠讀取哪些資源，可以認為授權的對象是由角色+資源（resource）+ 操作組成。資源是指菜單，功能，操作是通常含義的CRUD操作，用user story來描述是，這個角色能夠對哪些資源做哪些具體的操作。角色與資源之間是多對多的關系。

一個授權的例子：角色是倉庫保管員，可以訪問倉庫頁面，并對倉庫里的貨物進行出入和入庫操作。系統管理員為小明創建了一個xiaoming的帳號，并給xiaoming綁定了倉庫保管員的角色。結果就是：小明登錄系統后，能夠對倉庫的貨物進行操作了。

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

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