B端設計師必懂(一):RBAC許可權系統

語言: CN / TW / HK

電商行業中,後臺會有客服、採購、財務等不同的角色,對應展示不同許可權、介面資料。在設計B端後臺許可權模組時,簡單的用許可權勾選即可,然而複雜的需要涉及到多角色、多許可權相互匹配的場景中,則需要引入一個概念——RBAC許可權模型。本文作者對RBAC許可權模型進行了介紹,一起來看一下吧。

這是一篇 實戰經驗+概念解釋 文章。

想法來自近期在進行一個後臺產品中,涉及到許可權管理的設計,需要設計多種角色、並需要對應不同級別,需要區分不同許可權的設計,說半天,上個圖!

大概意思就是在D的角色下會有A、B、C這3人,而C又包含角色A、B的許可權,角色A、B下方又有A-1、B-1等人;而D擁有最大許可權,對應下分不同角色配對不同許可權,而下一級又是不同許可權!於是一層層套娃開始了!

做過電商行業的應該都知道,在後臺會有客服、採購、財務等不同的角色,對應展示不同許可權、介面資料。

這就要求設計師在設計時,就要從業務角度上,去對每個角色進行代入、根據實際業務理解後進行設計。

通常在設計B端後臺許可權模組時,需要先釐清角色與許可權之前的關係,比如對子賬號進行角色管理、許可權分配等場景進行分類,如果簡單一點的模式設計就很好處理,用許可權勾選即可,但複雜一點的就需要涉及到 多角色、多許可權相互匹配 的場景中,簡單許可權勾選就不足以支撐起許可權模組了。

因此,在B端後臺介面設計中,就需要引入一個概念: RBAC許可權模型 ,現今許可權設定幾乎都是在RBAC模型上進行擴充套件的,本文下面將會對RBAC許可權模型進行簡略介紹。

一、RBAC模型定義

那說起RBAC許可權模型,那我們來看下它在“維基”上的定義:

可以看到:RBAC是Role-Based Access Control的英文縮寫,意思就是以【角色】為基礎進行【許可權】的【控制】。

換句話說:就是 劃定【許可權】範圍,賦予【角色】,再將【角色】賦予【賬戶】 ,這樣【賬戶】擁有了許可權,許可權邊界會很清晰,而去命定賬戶許可權時只要去管理角色即可。

還是不懂?看圖:point_down:

例:RBAC簡單示例

再用王者榮耀來比喻:

  • 角色 == 英雄人物
  • 許可權 == 英雄技能
  • 賬戶 == QQ/微信賬號

使用【英雄人物】的就是你的賬戶,賬戶可以擁有多個英雄人物,管理許可權的時候只要去管理【英雄人物】就行了。

二、RBAC模型細項說明

在RBAC模型中,有三個比較重要的概念:

  1. 許可權:原子級別功能,能夠訪問某個資料或者進行某個操作的資格或權力
  2. 角色:分子級別功能,對某一類共同擁有許可權集合群體名稱
  3. 賬戶:組合功能,對擁有角色集合的群體名稱

下面對每個概念進行說明。

1. 許可權說明

在計算機系統中,許可權是指某個特定的使用者具有特定的系統資源的使用權力,在後臺管理中,系統資源指的是系統模組、頁面、操作功能等。

大致可以將許可權分為: 功能操作許可權、資料許可權

  • 功能操作許可權:在系統的操作、互動都是功能許可權,操作都需要頁面承載,所以包瀏覽頁面許可權、操作按鈕許可權都歸屬功能操作許可權
  • 資料許可權:對資料進行增刪改查

例:許可權的構成圖

2. 角色說明

角色是一定數量的許可權的集合以及載體,很好理解,就是界定好哪幾個角色擁有哪些許可權。

比如角色一擁有:檢視訂單、修改訂單價格、確認發貨、訂單評價 等許可權,那角色一其實定義的是客服角色,那就可以給角色一命名為【客服】。

如下圖所示:

例:新增角色操作介面

3. 賬戶說明

賬戶是對角色的囊括,也是角色集合的載體,即界定賬戶擁有哪些角色,對應擁有哪些角色的許可權。

如下圖所示:

例:賬戶對應的角色

4. 升級模型:RBAC1模式

上述所有模型是基礎模型,實際業務中僅有基礎模式是不夠使用的。

比如一個系統中有了角色:管理員、客服、採購、財務等。

但財務下會有多種角色,例如:總賬會計、明細帳會計、出納等角色,故此對RBAC模型進行升級,會把一開始沒有上下級關係的稱為 RBAC0模型 ,在RBAC0基礎上引入角色間的上下級關係,升級後稱為為 RBAC1模型

如下圖所示:

例:RBAC1模型

在RBAC1之後還有RBAC2、RBAC3等關係,較為複雜,不在本次討論範圍之內。

三、設計中引用RBAC模型的好處

RBAC中具有角色的概念,設想一下,如果系統中沒有角色,那麼需要設定每個賬戶的許可權,如果較複雜系統中,涉及到許可權都非常多,每個賬戶都單獨設定一遍,無疑是一件繁瑣且工作量巨大的任務,可以說引用RBAC模型可以大大提高生產力。

在還未引入模型時,需要對每個賬戶都進行許可權限定,參考下圖,線條代表了需要操作的次數。

如果引入角色後,只需要給 將角色給不同賬戶給角色賦予許可權,這樣賬戶擁有的角色就直接擁有了該角色下的所有許可權。

四、實戰:如何設計RBAC模型

1. 梳理許可權

可以對頁面當中擁有哪些可操作項收集,通常許可權都是由系統、頁面操作限定的,可以梳理一下產品整體框架,對所有許可權進行分類。

比如千牛商家後臺,在【店鋪】一級頁面下,擁有【店鋪管理】【商戶中心】【神筆】【營銷管理】四大許可權,在這四大許可權之下又擁有次級頁面,在次級頁面下擁有各個模組的操作,這樣從功能操作+資料上實現了集合。

如下圖:

例:千牛商家自定義許可權

2. 命定角色

從擁有【店鋪】整體許可權來分析,其實更多是關於到整體運營層屬性,所以在歸屬【店鋪】許可權,可以對應到【運營組長】【運營專員】等角色。

如下圖:

例:千牛商家命定角色

3. 賬號限定

其實對賬號的限定很簡單,重點是對賬號擁有哪些角色範圍圈定,圈定角色之後就隸屬於哪個部門使用賬號的問題了

如下圖:

例:千牛商家命定賬號

大功告成!完成這3步就完成整體設定啦!

總結一下

B端後臺許可權設計引入RBAC許可權模型設計,是基於角色進行的許可權訪問控制,再進行對角色進行賬號匹配。在進行產品設計時,儘量使用許可權、賬號分開模式去設計,而使用角色——許可權匹配模式來做解耦。

後臺類或者TO B內部產品,不會像C端使用者一樣許可權簡單,也不會追求極致使用者體驗,而是追求明確、結構清晰,不要在互動操作或文字上,讓使用者有疑惑,尤其針對許可權一塊,或涉及業務功能設計上,儘量減少歧義,避免造成返工、錯誤理解等情況。

另附帶RBAC模型升級概念解釋,下期見!

  1. RBAC0:是RBAC的核心思想
  2. RBAC1:RBAC基礎上增加了角色分層模型,即進行了角色上下級區分
  3. RBAC2:RBAC基礎上增加了約束模型,什麼是約束呢,就是賬號想要獲得高階許可權,必須先擁有低階許可權,否則無法命定
  4. RBAC3:其實是RBAC2 + RBAC1,雙重限定條件

本文由 @無塵弟弟 原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

給作者打賞,鼓勵TA抓緊創作!