案例演示:ToB領域的權限體系實戰

5 評論 10462 瀏覽 47 收藏 7 分鐘

文章從權限模型出發,結合具體案例分享了To B 的權限體系設計關鍵環節和需要注意的問題,與大家分享。

背景

之前在另一篇文章里介紹了權限體系的基礎概念如RBCA和ACL,網友反饋說不夠深入,需要來點見真章的東東,最好是能夠看完后,就可以直接拿到工作中投入使用的。聯想到工作中遇到的幾個都屬于ToB領域里,但面向不同業務方向和類型的實際項目,拿來具體討論一下,如何為平臺設計一個比較通用的權限系統。

原型圖

我這里用的是xiaopiu,在線繪圖。不用額外安裝程序。如果專業點的,一般會用axure,有一定的學習門檻。

從這張原型圖里,可以看到這是一個體現了權限體系核心功能的簡單系統。

  • 當王經理登錄的時候,不僅能管理系統概況,也能管理具體的實用功能也就是圍欄和視頻系統。
  • 當巡邏員小李和巡邏員小明登錄的時候,他們只能管理圍欄和視頻系統。
  • 通過賬戶和角色的組合,就能夠實現上面的要求

實現的原理是什么吶?首先來了解下資源的概念

背后的事兒

什么是資源

如果沒有【賬戶】和【角色】,這就變成了一個最純粹的功能系統了。這個系統由系統概覽和實用功能兩個一級菜單,以及下層的各個細分功能組成。

第一步需要用標識,來標記這些功能。通俗的,可以將這些功能命名為資源,后臺數據庫中就是通過資源ID來識別某一個具體的功能的。

頁面上的每個元素都要有對應的資源ID,這是為了在前端展示的時候,能夠做到讓不同用戶登錄后,有的用戶可以查看,有的可以編輯,有的可以刪除。

所以第二步,需要定義對各個資源ID能夠進行的操作,也就是資源和操作之間會產生一個映射關系。

資源和操作

操作的含義,可以理解為CRUD(創建Create/讀取Read/更新Upate/刪除Delete)四種類型。一般實際實現過程中,為了不這么麻煩,可以將這四種操作簡化為全有或者全無。用映射關系來表示就是

resourceId -> CRUD

實際實現的效果就是,當用戶能夠看到這個資源,那他就可以操作這個資源。如果真的遇到了有特定的需求,就是對于同一個資源,這一種類型的用戶必須有而且只能有查看的權限,同時必須沒有編輯的權限,那么就需要將這個映射關系打散為如下格式

resourceId -> R

resourceId -> CUD

接下來,準備工作都做好了。鐺鐺鐺,將進入重頭戲,賬戶和角色。

角色

從業務流程上來講,是先有角色,再有賬戶。所以需要先創建一個角色。

王經理是一個賬戶,他有一個叫做“經理”的角色。系統中新增一個角色的時候,一般至少有3個字段,分別是角色的名稱(必填),角色擁有的資源的權限(必填),對于該角色的描述(可選)。對于各項的要求如下:

  • 角色的名稱不允許重復,如果有多個同樣名稱的角色,被賦予的權限還不一樣,系統就亂套了。
  • 對應的資源權限。也就是上面提到的resourceId+CRUD的組合。當然支持多選。也就是同一個角色,可以擁有對多個資源的權限

根據上述描述,在系統中創建兩個角色

  • 經理角色。具有對資源【系統概覽】和【實用功能】【圍欄】【視頻】的權限。這里要特別提一下,雖然將實用功能和圍欄分成兩個資源提了,但是實際操作時,當選擇了圍欄功能時,由于它是實用功能的子節點,默認直接將實用功能的權限也給這個角色就可以了,既簡單又不會造成更復雜的情況
  • 巡邏員角色。具有對【實用功能】【圍欄】【視頻】的權限

賬戶

萬事俱備,只欠東風。最后一步就是新建3個帳戶。賬戶新建的時候,需要填寫的字段,除了賬戶名稱(當然賬戶名稱也是不允許的重復的)和本身這個系統要求的一些信息(例如照片,手機號,電話號碼等)以外,就只需要一個字段【角色】了。

這里的角色字段的取值,來自于上一小節里提到的【角色】。一個賬戶,可以綁定多個角色。不同的賬戶,也可以綁定同一個角色。

為了讓王經理,小李,小明能夠正常服務于自己的崗位,實際上就是:

  • 新建一個賬戶,王經理,綁定的是之前創建好的 經理角色。
  • 新建一個賬戶,小李,綁定的之前創建好的 巡邏員角色
  • 新建一個賬戶,小明,綁定的之前創建好的 巡邏員角色

然后這三個人,用自己的帳號密碼登錄就可以了

總結

在一個真實的系統中,進行權限操作步驟是:

  • 第一步定義自己系統的資源權限映射關系,權限是由資源+操作組成的
  • 第二步創建角色,這個過程會將角色和對應的資源權限綁定
  • 第三步創建帳號,這個過程會將角色和帳號進行綁定

另外,映射關系為

  • 資源和操作:多對多
  • 角色和權限:多對多
  • 帳號和角色:多對多

 

本文由 @花生草 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的啥東東啊 ??????

    回復
  2. 很棒,有沒有對數據權限的梳理?

    來自福建 回復
    1. 沒錯,數據權限是一個典型的場景。這里的是1.0的版本,2.0的版本整理后再放出和大家討論

      來自北京 回復
  3. 如果有賬戶角色,賬戶,從業者,從業者角色,這個權限系統又該如何設計

    來自四川 回復
    1. 很好的問題,目前這個模型簡單而典型,實際的事業單位中,一定會有崗位和組織的概念。整理后再放出和大家討論

      來自北京 回復