文章從權限模型和概念出發，對權限系統的核心進行剖析，抽象出權限系統中的核心要素，並結合案例對權限系統進行介紹。
一個最簡單表達了權限模型的實例
小明和小李，分別用自己的帳號和密碼登錄了同一個平臺頁面。小明登陸上去後，可以看到小說和視頻頁面。小李登陸上去之後，只能看到小說頁面。
emmm…..他倆有不同的權限。
後臺是什麼樣的模型來實現的呢。對於ToB領域的權限控制，產品經理經常用到的是RBAC模型
什麼是RBAC
RBCA是英文role-based access control的縮寫，即基於角色的權限管理系統，用來實現對用戶授權，訪問系統的特定部分，實現不同粒度的權限控制。可以理解為一種非功能性的需求，而是一種安全機制。據說一般一個企業超過500名員工，都會需要用到權限控制。至於“安全”這個主題，在對企業打分的時候，不一定會成為一個加分項，但一定可以成為一個扣分項。
RBAC的核心是角色（role）。所有使用者的能夠操作的內容，都是通過角色來進行賦予和禁止，而不是直接通過對使用者本身來繼續賦予和禁止。如軟件行業的行話，當一個系統太複雜了，那麼就為他加一個層吧。同理，這樣一個role層加入是為了簡化複雜度。具體原因可以看
RBAC和ACL的區別下面來看一下，如果用戶要執行一項操作，需要滿足的RBAC的繞口令似的3原則
- 角色分配：一個用戶必須被分配一個角色
- 角色授權：當前角色必須被授權給當前用戶
- 權限授權：權限必須被授予給當前用戶的角色，當前用戶才能執行這項權限
RBAC和ACL的區別
傳統的ACL是屬於更底層更基礎的數據對象的權限控制，比如一個文件可以讀寫的權限控制。RBAC是帶有業務含義的權限控制。比如可以表達出銀行業裡，保險箱需要的開啟需要銀行經理和儲戶的鑰匙同時存在。又比如可以表達出業務流程中不能出現“自己審理自己”的這種荒唐現象。
權限體系與帳號體系的關係
賬號體系包含的內容是用戶帳號的註冊/登錄/密碼修改/密碼找回功能。其中用戶帳號登錄，就會需要權限系統提供的功能來進行協助校驗。
校驗內容包含：
- 這個用戶是不是被禁止，是否可以登錄系統。
- 這個用戶登錄後，能夠看到哪些頁面
- 在他能夠訪問到的頁面上，能夠執行哪些操作
權限體系與組織架構的關係
組織架構是企業的行政組織架構。企業所使用的系統，都是其組織結構的反應。所以任何一個ToB的系統，如果要獲得客戶的認可，必須符合客戶的組織結構。
大型企業的組織架構會相當複雜，比如國家電網這種重量級選手，有職能部門，地區分部，一級省公司，直屬單位，再往下細分那就更多更復雜了。如果小型公司，可能就只有公司總體和部門兩個級別，比較簡單。可以想見，對於越複雜的組織結構，所要求的權限控制的精細度，權限限制會更加複雜
權限體系與組織架構能夠一眼所見的，最直接的關係，就是數據。組織與組織之間的數據，應該是隔離的，組織A的人員，不能夠去訪問和操作其他組織的數據。這些需要通過權限體系來實現。
簡單權限系統的設計
如前所述，首先需要設計的是角色。
1. 角色分離
一般角色可以按照兩種維度進行分離，管理的維度和業務的維度。
- 管理角色：一般是企業的運維人員，可以登錄系統，進行維護和授權操作。一般通過自定義的方式，可以支持頁面上新建。一般一個賬號可以同時有多個自定義角色
- 業務角色：按照職責進行確認，比如財務，保潔員，總經理等。一般通過內置角色的方式來實現，不支持頁面上新建。一般一個帳號可以有一個內置角色
上面說的是一般，一般，一般。當然實際情況中總會有新的不同情況
管理角色會發生變化，但是業務角色由於和企業的組織架構，職級，職能相綁定，一般創建好之後是不會發生變化的。
2. 用戶分配角色
參考RBAC三原則，當系統中新建一個用戶時，必須為這個用戶分配一個對應的角色
3. 角色授權
不管是內置角色還是自定義角色，當新建一個角色時，需要為這個角色進行授權。permission是一個操作，定義了能夠讀取哪些資源，可以認為授權的對象是由角色+資源（resource）+ 操作組成。資源是指菜單，功能，操作是通常含義的CRUD操作，用user story來描述是，這個角色能夠對哪些資源做哪些具體的操作。角色與資源之間是多對多的關係。
一個授權的例子：角色是倉庫保管員，可以訪問倉庫頁面，並對倉庫裡的貨物進行出入和入庫操作。系統管理員為小明創建了一個xiaoming的帳號，並給xiaoming綁定了倉庫保管員的角色。結果就是：小明登錄系統後，能夠對倉庫的貨物進行操作了。
本文由 @花生草 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
