B端平臺權限體系設計:RBAC模型的技術實現邏輯
編輯導語:這篇文章基于B端平臺的權限體系設計,細致地闡述了作者對于RBAC模型的理解,并向我們展示了RBAC模型的具體應用和邏輯實現過程。感興趣的話就一起看一下吧。
在以往多個0~1大型數字中臺項目中,底層權限體系是我最關心的,也要求產品經理和開發同學、尤其是后端開發必須熟悉后方可進入產品開發項目。
RBAC模型給了B端產品非常容易理解的權限方法,平臺中也有很多RBAC相關的文章介紹。本篇重點介紹實際的技術實現過程,供大家參考,方便B端產品經理與開發同學的溝通,避免走彎路(曾經3個項目在此處折損頗多)。
一、權限體系的基礎介紹
權限體系的要素有:業務組織、角色、用戶和權限、頁面、視圖。
- 組織、角色、用戶是基于業務變化可即時調整的。
- 權限是最底層屬性,由開發人員基于業務需求開發實現。權限約束的對象是后臺的具體實例。根據數據接口安全需要,可設計專用的接口權限。權限分功能權限(含菜單權限)、組織權限、數據權限。
- 頁面、視圖是系統按照業務配置、給對應用戶呈現的內容。
詳細的權限體系說明,可參考 《成熟CRM系統的權限體系解析》 一文。
二、對RBAC模型的深度理解
RBAC(基于角色的權限控制)模型的核心是在用戶和權限之間引入了角色的概念。取消了用戶和權限的直接關聯,改為通過用戶關聯角色、角色關聯權限的方法來間接地賦予用戶權限(如下圖),從而達到用戶和權限解耦的目的。
RBAC模型強調了用戶、角色、權限間的關系,但在B端業務應用中是不能脫離業務部門存在的,因此4者必須建立關系。除了以上4張表外,后臺還需記錄用戶、業務部門、角色的關系表,如下圖:
1. 成熟業務平臺中對業務記錄的基礎要求
成熟ERP、CRM平臺中權限體系非常嚴密,對業務記錄有嚴格的要求:即單條業務記錄中必須有業務記錄的Owner和Owner所屬的業務部門。因此,業務記錄必須有7個基本字段:創建人、創建時間、最后修改人、最后修改時間、Owner、Owner所在的業務部門+狀態(啟用/停用),當Owner發生變化時,Owner所在的業務部門同步更新。
只有如此,才能保障組織權限的嚴格控制,其實現邏輯:按照當前用戶所在的組織和角色的數據范圍來從數據記錄中的Owner所在的業務組織來獲取的。加載可見數據后,再根據當前用戶的編輯等權限進行前端的功能按鈕控制。
舉例:張三是銷售經理,查詢權限是看見部門所有銷售顧問的客戶數據,修改權限是個人的。在獲取客戶列表時,部分客戶的修改按鈕是高亮的(他個人的客戶)、部分客戶的修改按鈕是置灰的(不是他的客戶,是其他銷售顧問的)。上圖中,客戶數據在線索中心中,其他業務中心的業務數據類似處理。
2. 權限體系如何配置和邏輯實現的呢?
權限配置屬于基礎設置部分,一般由超管用戶設定不同角色的權限,示例:
這樣的權限配置實際上需要前后端約定的,采用統一的權限碼來協同控制,使用excel表等其他方式約定菜單/功能權限、數據權限和對應的權限代碼。示例:
留3個需要大家思考的問題:
- 組織權限是個人級、全部和本部、本部及以下的處理方式一樣嗎?
- 如果一個人擁有多個角色、且不同角色的組織權限的級別不同,怎么處理?
- 有功能權限就一定可以處理業務記錄嗎?
三、更復雜應用:房產銷售中的業務組織+項目組織
在房產銷售業務中,會有業務組織,也會有項目組織及項目相關的業務數據,如:一個樓盤就是一個項目,這個項目上產生的線索歸屬于項目,客戶歸屬于整個體系,發展的渠道公司也是歸屬于整個體系。
業務人員會在充當不同業務角色和項目角色,復雜的如一個人同時在多個業務組織中、多個項目組織中,比如張三在BJ城市小區中任項目助理(擁有整個小區中的線索數據查看權限),同時在A項目任銷售一組經理,B項目(非BJ城市小區)中任銷售二組的案場顧問。此用戶在點擊線索列表時(項目外),看到的是BJ城市組織下的線索+A項目銷售一組的線索數據+B項目中歸屬自己的線索。
這樣的結果,就需要業務記錄中既要有業務組織ID、還要有項目組織ID。
四、擴展知識:各類平臺中的組織
- 行政組織:HR、OA等使用的行政組織,組織架構清晰。
- 財務組織:財務預決算使用的組織,比如行政組織中有1~5級,但在財務體系內直到3級,那4、5級組織對應的財務組織就是3級。
- 業務組織:業務運營的組織架構,與行政、財務組織類似,但會不同。舉例:董事長下CEO、CEO下CMO+CFO,但業務系統中會將董事長、CEO、CMO、CFO均放在公司頂級組織里,甚至財務會計、BP均會放在公司這層。
- 虛擬組織:常用于區域管理組織或職能組織,比如與華南大區平行的華南虛擬組織中,會有財務、HR等職能共享組織,也會有負責市場物料集中采購的采購專員等。同一個財務會監管2個大區,即在2個大區虛擬組織中,數據范圍是按照平行的華南大區業務組織的權限。
作者:王建儒,MBA,科技公司CPO,18年業務運營、運營平臺規劃與建設經驗。微信公眾號:王建儒的B星球
本文由 @王建儒 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
專欄作家
王建儒,微信公眾號:王建儒的B星球,人人都是產品經理專欄作家。18年業務運營、運營平臺規劃與建設經驗,熟悉S2B2C業務模式的業務+數字雙中臺規劃和落地,聚焦汽車、房產等行業的營/銷/服/客戶運營與數字轉型。甲方IT負責人、乙方業務專家/產品團隊負責人。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
訂閱了
厲害!
受教
1.組織權限是個人級、全部和本部、本部及以下的處理方式一樣嗎?
答:【不確定】處理方式是指?
2.如果一個人擁有多個角色、且不同角色的組織權限的級別不同,怎么處理?
答:會擁有所有角色的權限之和。
3.有功能權限就一定可以處理業務記錄嗎?
答:不一定,還要判斷是否有組織權限、數據權限。
第二個問題,如果兩個角色互斥,是否需要考慮讓用戶只能選擇一個角色?
是的,這是必須的。比如出納和會計就不可以為同一人。
1-處理方式不同:1)個人級權限,直接找owner;2)全部:直接給所有數據;3)本部:給owner所在組織的ID、用此ID返回記錄中有此ID的數據;4)本部及以下:owner所在組織的ID及以下所有組織的組織ID,用這些ID返回記錄中有這些ID的數據。
2-從數據查看角度,取最高級別的權限;但部分業務數據敏感,就會取最小級別的權限。避免因角色權限配置錯誤,而造成數據泄露。
3-一般的有組織和數據權限才會涉及到功能權限,即先看到了數據記錄,才可以修改、刪除。而且功能權限用戶中心都會同步給業務中心的。這里想強調的是業務邏輯控制,如訂單狀態對功能權限的影響,舉例:訂單關閉后,只有查看按鈕、歸檔按鈕,其他按鈕全部置灰。
超贊,收獲很大
贊