在B端業務場景下，不同的角色會在不同的場景下使用產品。所以說，用戶與角色權限是必不可少的一環。
站在巨人的肩膀上看問題，目前市場上普遍使用的RBAC權限模型。
一、了解RBAC
RBAC（Rloe-Based Access Contol），基於角色的訪問控制，就是將用戶通過角色與權限進行關聯。其實就是構建了“用戶-角色-權限”的授權模型。
具體做法是，先給系統配置好各個角色及對應權限，然后創建/注冊用戶時，給用戶配置對應的角色。具體順序如圖：
二、了解權限
角色權限大致分為兩種，功能權限與數據權限。
功能權限比較簡單，就是規定該角色是否能進行某種操作。功能權限的設計需要考慮顆粒度問題：既可以設置該角色能否進行該頁面的所有（某個）操作，也可以具體到該頁面某個操作，該角色能否操作。例：訂單管理系統-訂單頁面，財務角色可以導出訂單報表，但財務角色沒有下單操作權限。
數據權限則是規定該角色能看到哪些數據。同樣的，數據權限也可以關注顆粒度，可以規定角色能看到哪些頁面，也可以該頁面具體哪些字段是該用戶可以查看的。但一般來說，若該角色沒有該頁面的數據權限，默認也無功能權限（頁面都看不到，更別談什么操作了）。
事實上，當用戶涉及到所屬組織，權限的設計會變得更復雜一些。
三、RBAC的拓展
① RBAC0模型
若不考慮角色的組織關系時，上述就功能及數據權限已經夠用了，這種基礎模型就是“RBAC0”模型——權限賦予角色，用戶分配角色，角色與用戶之間可以多對一，也可以是多對多的關系。
②RBAC1模型
上面權限提到有時需考慮用戶組織架構的問題。
舉一個例子：某集團總部可以查看其子公司的所有數據，且子公司僅能操作本公司及以下本公司該部門下的功能，但不可操作別的子公司或總部的功能。
這里就涉及到公司架構的問題，由此RBAC變化出了第二種模式——RBAC1模型。基於RBAC0模型，加入角色之前的繼承關系，引入“角色等級”的概念。
我理解的RBAC1模型有以下原則：
- 高級別角色創建的必須為低級別角色，不可平級創建。
- 低級別角色維護權限時，僅能維護比其低級別的角色，高級別或平級角色無權限維護。
- RBAC1模型只規定該角色能否操作某功能。
這時你是否會產生這樣的疑問：RBAC1僅規定角色的功能/數據查看權限，那具體能看到哪些數據又怎么決定呢？
當我了解完RBAC1模型的知識后，我就產生了這樣的疑問。后來重新理了一下邏輯，角色權限並不能幫助我們規定某二級用戶應該查看什么數據，真正規定查看數據的應該是“用戶與組織架構之間的關系”。
回想一下上述的例子，集團能夠查看旗下所有子公司的數據，但A子公司某個部門（相當於用戶）也僅能查看到A子公司的數據，無法查看別的子公司，由此可以得到的結論是：低級用戶所能查看的數據為其所屬組織所能查看數據的子集。
所以在創建用戶或用戶注冊的時候，需要同時維護該用戶所屬組織、角色類型這兩個重要信息。借由這兩個信息，可以解決該用戶的功能、數據權限的問題。
③RBAC2、RBAC3模型
前面也有提到一個用戶可能會擁有多個角色，RBAC2模型主要是對角色的訪問進行控制，應用某些限制條件，限制該用戶在登錄之后僅充當其中一種角色。這種場景在我工作中應用的場景還沒出現，便沒有過多的了解。
RBAC3模型，則是將RBAC1、RBAC2進行整合，僅有角色分級，又有限制條件。
四、總結
上訴基於我的理解，我認為“用戶-角色-組織架構”三者是不分家的。具體順序為先有角色與組織架構，再添加用戶/用戶注冊時，分別配置角色，組織架構，最后完成功能、數據權限的約束。
RBAC模型自創建以來有着許多分化，具體使用哪種分化模型還需要產品經理根據實際使用場景進行抉擇。其實RBAC模型還不僅如此，還有“用戶組”等其他概念，這里不多作闡述，有興趣的小伙伴可以自行找資料。