三個模塊,搭建后臺用戶角色權限管理系統

11 評論 129273 瀏覽 401 收藏 15 分鐘

一個后臺的用戶角色權限系統總是可以大概劃分為三個打的模塊的:用戶管理、角色管理、權限管理。本文作者將就此三個模塊展開敘述,enjoy~

一. 用戶角色權限系統說明

1. RBAC權限設計模型

(1)RBAC

(Role-Based Access Control,基于角色的訪問控制),就是用戶通過角色與權限進行關聯,從而獲得某些功能的使用權限。權限被賦予給角色,而不是用戶,但是一個用戶可以擁有若干個角色,當一個角色被賦予給某一個用戶時,此用戶就擁有了該角色所包含的功能權限。簡單地說,一個用戶擁有若干角色,每一個角色擁有若干功能權限。這樣,就構造成“用戶-角色-權限”的授權模型。在這種模型中,用戶與角色之間,角色與權限之間,一般者是多對多的關系。如下圖:

2. 三大模塊搭建后臺用戶角色權限系統

如上所述,一個后臺的用戶角色權限系統總是可以大概劃分為三個打的模塊的:用戶管理、角色管理、權限管理。用戶管理往往隨著行政部門劃分或者隨著業務線部門劃分,對應部門或者小組內的用戶有著基本相似的功能需求和權限等級;角色管理相對來講更加固定,它往往是基于業務管理需求而預先在系統中設定好的角色標簽,一般不會隨意更改,更像是一個用戶分組標簽;權限管理內容相對更加龐雜和豐富,主要包含了目標、操作和許可權三個部分,當某一功能權限授權給用戶時,也就相當于為該用戶開通了可以操作某個目標功能的許可權。

角色權限系統屬于策略設計的范疇,它的設計非常考驗一個PM對業務的理解力以及對自己后臺所有功能的熟悉程度。做角色權限系統之前一定要先深度了解業務流程以及后臺的所有功能模塊,在不了解的情況下,多向相關同事請教,避免角色權限系統設計過程中出差錯和邏輯漏洞。

二. 用戶角色權限系統建設的三大模塊

1.? 用戶管理

用戶管理中的用戶主要是功能系統的使用者,這些用戶是一個一個的員工個體,這些個體往往從兩個維度來進行劃分:行政關系(部門架構)、業務部門(業務架構)。用戶管理就是在此兩個維度來給員工個體進行關聯性的初步分群或者分組。按照行政部門或者按照業務線部門劃分后,對應部門或者小組內的用戶有著基本相似的系統功能使用需求和權限等級;

注:上圖例為按照行政關系劃分的用戶管理模式

注:上圖例為按照業務線關系劃分的用戶管理模式

2. 角色管理

(1)角色管理

角色往往是基于業務管理需求而預先在系統中設定好的固定標簽,每個角色對應明確的系統權限,其所擁有的系統權限一般不會隨意更改,并且角色也不會隨著用戶的被添加和被移除而進行改變,相較于用戶管理而言更加穩定;

(2)自動賦權:用戶自動進入角色

如果角色與行政關系下的組織部門存在綁定關系,那么如果一個用戶進入到該組織部門后,該用戶會自動被加入到對應的角色中,并且擁有該角色所有的系統權限。如一個財務人員【小張】入職財務部后,那么該用戶無需進行額外的授權即可在對應財務報表系統查看該部門員工可查看的財務數據報表和對應的操作權限(比如操作財務審批等);

(3)角色賦權:用戶被添加進角色

業務是不斷創新和發展的,隨著業務的發展,會有越來越多的新的角色被設置和創建,比如公司新啟動了一個企業團餐項目,項目部橫向的從各個部門找了多個員工組建項目團隊,并且該項目的業務權限也只是授權給這批員工可查看和操作,那么,在此項目中,會產生一個新的角色 “ 財務1 ”,系統高級管理員會把從財務部門選中的財務【小張】添加到“ 財務1 ”這個角色中,那么【小張】即可獲得查看企業團餐項目業務數據報表和操作的權限。這種權限的授予無法通過用戶行政關系的自動綁定來實現;

(4)角色繼承:角色權限的繼承

權限可以是獨有的,也可以是繼承的。每個角色都有自己的權限集,角色繼承其實也就是繼承父系角色的權限,一般角色在繼承其父系角色的全部權限的基礎上增加擁有一些自己的權限。而系統角色繼承往往存在于用戶分級管理比較明確的團隊或者公司;

(5)角色互斥:角色包含的權限互斥

角色互斥的業務背景:當一個業務流程由于風控的原因,需要將其操作給劃分成分開的幾個步驟時,需要給這幾個不同的步驟授權不同的角色,并且這些角色之間需要進行互斥。比如大額財務報銷審批流程,財務人員【小張】擁有了審批人權限后,就無法將審核確認的權限再授予小張,以此來規避一個人完成大額報銷而帶來的財務風險;

(6)臨時角色

臨時角色往往是針對特殊群體設置的,比如公司有特殊訪問團隊蒞臨,需要給這些特殊的客戶一些臨時身份來體驗某些功能操作。那么把這些人添加到部門的組織架構中顯然是不合適的,因為這些人只是臨時的擺放者,不是企業員工;其次,這些客戶需要體驗的功能操作往往是橫跨多個業務模塊和產品線的(比較繁雜),一般公司并沒有現成的固定角色符合擁有客戶所需的全部操作權限,因此需要給這些客戶開設臨時角色,并且支持給臨時角色最大的權限選擇空間;

(7)黑白名單

3. 權限管理

(1)權限管理

權限管理更多是從功能菜單、功能操作、數據參數三個不同顆粒度等級來考量的。具體顆粒度的大小視公司結構和團隊規模而定,如果不是業務屬性一定要求將權限控制到非常精細的級別,其實就沒有必要將權限的顆粒度拆分到具體某一項操作或者某一個按鈕,畢竟后臺產品的核心是業務管理平臺,主要目標是輔助業務的管理和推進。

注:如圖為某一后臺產品的部分截圖,其中可見功能菜單頁、功能操作按鈕和數據字段。

(2)功能菜單權限

對于后臺產品來講,針對功能菜單來劃分用戶權限其實是比較粗顆粒度的一種管理方式,這種模式下用戶一旦獲得授權即可使用該菜單欄下的全部數據查看權限和功能操作權限;

(3)功能操作權限

功能操作層級的權限相對于功能菜單會更為深入,這種情況下,不同角色的用戶可以進入同一菜單頁后臺查看相同的數據字段信息,但是他們可執行的功能操作不同;

(4)數據字段權限

數據字段層面是較細顆粒度的拆分,他會實現不同角色用戶在進入同一菜單頁后臺時,可見的數據字段都有差異。比如銷售人員進入某銷售業績管理后臺時,可以看到自己的業績提升數據,但是財務人員看到的是業務工單的費用字段,這些字段共存在一個菜單頁中,只是受限于不同的角色權限而已。

三. 案例分析

1. 促銷活動權限系統權限對接

以某一促銷活動的后臺從無權限限制到接入用戶角色權限管理系統為例,詳情如下:

注:以上為某產品的促銷活動管理后臺截圖

2. 促銷活動后臺接入權限系統前

在促銷活動后臺接入權限系統之前,幾乎全部的系統權限都處于裸奔的狀態,所有人業務線成員都可以查看該后臺的運營活動內容和運營結果數據,并且可以執行相對敏感的操作。這種情況顯然是存在一定的管理風險的,因此該后臺系統需要對接權限管理系統進行系統化管理和風險控制;

3. 促銷活動后臺接入權限系統時

促銷活動在接入權限管理系統過程中,需要拆解該功能模塊的權限元素(到一定顆粒度),因此需要根據業務特征來判斷需要拆分的顆粒度,是到功能菜單、功能操作還是數據字段的級別,明確拆分顆粒度之后,權限管理系統才可以給不同角色按照顆粒度授予權限;

4. 促銷活動后臺接入權限系統后

促銷活動在接入權限管理系統過程后,當對應角色的用戶再次登錄這個后臺時,首先后臺會校驗該用戶的角色是否擁有該功能模塊的權限,以及該角色權限對應的操作權限和數據字段權限,校驗結果經服務端處理會在產品端展示給用戶可見。這個時候,同一用戶再該后臺可見和可執行的操作與接入權限管理系統之前可能有很大的不同,這就是基于用戶角色的權限管理系統帶來的改變。

四. Q&A

1. 一個用戶擁有多個角色,多角色之間如果存在互斥關系如何處理?

如果一個用戶已經被添加到某一角色范圍下,那么,當給該用戶添加一個與當前角色存在權限互斥關系的角色時,系統會進行互斥性判斷,后面的角色就無法給該用戶添加成功;

2. 業務發展過程中,如何保證不同角色之間權限拆分清晰?

隨著業務的快速發展,一定會不斷新增不同的角色和更多的功能模塊,而且這些角色和功能權限之間的關系也會日益混亂,這個時候需要產品經理和業務方一起,及時的面對業務的發展變化,及時、快速的梳理業務調整范圍,作出對應的改變;

3. 用戶權限管理系統核心難點是前期的產品設計嗎?

用戶權限管理系統核最難的不是前期的產品設計,而是后續的運營維護,因為權限系統的結構往往不會隨意變更,但是隨著業務發展快速出現的角色和功能模塊,為了防止角色和功能權限之間的關系變得混亂,在建立新的角色和分配權限的時候需要思路清晰且慎重調整。

完結~

 

本文由 @陽明(劉同) & @云殊(張俊恒)原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 反復研讀多遍

    來自廣東 回復
  2. 很受用,原來對于角色橋梁的作用理解不深,本文中關于角色的自動賦權、角色繼承、角色互斥的功能加深了我對角色的理解,對現有工作也有所啟發。感謝分享。
    針對權限管理這塊有沒有更深入介紹的文章可以學習,求推薦

    來自福建 回復
  3. 請教下大佬類似下面問題如何設計:
    x公司銷售部門,分a、b兩組
    1.a組長可以查看、修改、審批a員工表單,
    2.a組成員可以查看b組表單
    3.b組長在a組長授權的情況下可以代為審批a組成員表單
    4.a組、b組成員只能查看管理a組,無法看到b組表單(這種同部門的銷售訂單用的相同頁面)

    回復
    1. 不是大佬,簡單說下
      1、補充一下前提信息,
      1.1先統一名詞,a/b員工表單,a/b組成員表單,a/b組皆統一為a/b成員表
      1.2假設a組長只能管(增刪改查)a成員表
      1.3假設b組成員只能看a成員表,看不到b成員表(1、4矛盾,1說a可以看,4又說可以管理,暫定為成員只有看的權限)
      1.4a員工,和a組長的可視范圍一致(能看的信息一樣)
      1.5員工表單,通常指的是展示員工信息的表,而審批的單,通常指的是一些工單的表,和員工信息表不同,暫時定為在員工信息上有個和修改類似的審批操作
      1.6假設b組長對b成員表也有查看、修改、審批權限
      2、入正題
      2.1建立一個成員表,記錄員工信息,包含兩個字段{所在組}和{職務}
      2.2當發生操作行為時,比較動作【發起者】和【接受者】的信息
      2.3所在組為a的【接受者】信息可被所有人查看
      2.4所在組一致,且【發起者】職務為組長
      則可進行增刪改查
      2.5所在組為b,且職務為組長的【發起者】,可對所在組為a,且已被a組長授權的【接受者】信息進行審批。
      2.5.1至于這個a組長授權又有多種情況:
      2.5.1.1如a組長提前授權了一批員工,此時b組長才能看到對其審批的功能,不然就只能看不能審批
      2.5.1.2又或者b組長一直都能看到審批功能,但是他點了之后,需要經過a組長授權(二次確認)
      信息不全,先說到這,有興趣(或者工作機會)可以加微信(用比較多),同號QQ:493412629聯系一下●v●

      來自廣東 回復
    2. 第1.3點說錯了,矛盾的不是1、4,是2、4.。。。

      來自廣東 回復
    3. 好久沒登錄這個網站,回答了這么多,感謝!

      來自安徽 回復
  4. 角色創建和編輯操作權限、數據權限是靈活的,但是有些功能需要把角色寫進代碼,怎么處理這種事件?
    比如我把角色1寫進代碼,角色1有某些操作和數據權限,但是在后臺編輯角色時又重新編輯了,導致功能實現層面發生了變化。

    來自上海 回復
  5. 02功能操作權限和03功能操作權限許可,有什么區別?需要分拆分出來?原因: 在賦予角色操作某某的權限時,同時也就被許可了。

    來自四川 回復
  6. 在這種模型中,用戶與角色之間,角色與權限之間,一般者是“多對多”的關系 這里應該是 “一對多” 關系;

    來自廣東 回復
    1. 一個用戶有多個角色;一個角色賦予多個用戶。 權限就不說了,更是了。。。。

      來自四川 回復
  7. 這不是基于資源的RBAC系統嗎?

    來自浙江 回復