后臺系統:賬號權限系統設計

70 評論 88076 瀏覽 747 收藏 7 分鐘

文章對賬號權限系統設計展開分析,希望能夠給你帶來些啟發。

一、系統概述

一個賬號權限管理系統,主要包括三個元素:賬號、角色、權限。我們所要管理的,也就是賬號、角色和權限之間的關系。

賬號:基本上所有的應用,無論是移動端,PC端,C端或B端產品,登陸都需要一個賬號。只是對于C端的產品,都是用戶自己注冊即可。而對于后臺產品而言,是需要公司內部人員去創建賬號的。

角色:所謂角色,就是用來控制各個賬號的操作范圍的,可以理解為權限組。因為一個系統中權限太多,我們不可能每創建一個賬號,就去挨個設置一遍權限,因此可以根據不同的部門、職級、工作內容等來對權限進行分組,制定成不同的角色,這樣,在創建賬號時,就可以直接賦予賬號不同的角色,從而把角色擁有的權限給到這個賬號。

權限:包括數據權限、操作權限和頁面權限。

一、數據權限:即賬號可以看到的數據范圍,比如一個旅游行業的公司管理者能看到公司的所有數據,而亞太部的人只能看到亞太部門產生的數據。在設計過程中,數據權限控制的難易程度與業務和公司部門設置的復雜程度有關。

二、頁面權限&操作權限:頁面權限即賬號可以看到的頁面內容,操作權限即用戶可以進行操作的內容,如增刪改等。在產品設計的過程中,可以將操作權限和頁面權限結合起來做到一個集合中,創建角色時將權限賦予給角色即可。

系統的主要流程為:將權限設置成不同的集合,即角色,再將角色綁定到賬號上,那么這個賬號就擁有了這些角色的權限集合。一個賬號可以綁定多個角色,一個角色又擁有多個權限。

如上圖所示:用戶A擁有了角色1和角色2兩個角色,從而擁有了“增加、刪除、審核”的權限。

二、實例設計

1、賬號管理

添加/編輯賬號:

在創建賬號時,一般都需要填寫基本信息和設置角色?;拘畔⒅饕ㄐ彰?,部門,賬號備注等等,不同企業需求不同。
此外,為了控制數據權限,還可能會有賬號等級的選擇、賬號關聯、上下級關系綁定等操作。具體流程視設計情況而定。

2、角色管理

添加/編輯角色:

需要說明的是,角色不能隨意刪除或禁用,需要判定該角色有沒有被哪個賬號綁定,若該角色正在被使用,則不允許刪除并給出相應的提示。

三、經驗之談

1、事先可以對賬號進行一個等級劃分(根據實際業務制定劃分規則),然后可以根據等級來判定數據權限。如等級為公司高級管理者,則可以看到所有的數據,而等級為分公司管理員,則根據分公司的ID或者名稱去獲取對應的數據等。不過這個只能做一個比較粗略的控制,僅一個等級來控制數據權限是遠遠不夠的;

2、考慮是否需要提供賬號與賬號之間做數據關聯的入口。當然,這是屬于比較特殊的情況,當設計的控制數據權限的規則都不能滿足的時候,是否需要為特例提供操作入口;

3、考慮是否需要提供一個賬號和數據之間直接做綁定的入口?如:等級為分公司管理員,由于業務需求,需要看到另外一個分公司的某條數據,該如何實現。當然,這里只是舉了一個很簡單的例子,實際實現時會有很多更細節和深入的問題;

4、若大部分賬號在權限上都存在差異,那是否每個賬號都需要有一個設置詳細權限的地方,而僅把角色當做一個快捷選擇的方式。(若不是必需,最好不要采取該種方式,這樣會破壞權限的規范性,不利于維護和管理);

5、創建角色(權限組)之前,需要明確各個部門之間的業務范圍及權限(包括頁面權限和操作權限),并將這些人就行劃分;當然,隨著公司的業務和后臺系統功能的改變,各個角色的權限是需要不斷完善和調整的;

6、在一些系統流程中,還需要為權限設置互斥關系,這樣的話,擁有互斥權限的兩個角色就不能同時綁定給同一個賬號了。是否需要這一步操作,需要根據業務情況而定;

7、對于一些基礎的賬號,在創建賬號時,是否需要直接根據賬號等級綁定默認角色(即給以默認權限)。

暫時想到的就是這些,后面想到了會再繼續補充。

小小產品一枚,文章純屬工作中個人經驗總結,歡迎大神拍磚指教。

 

本文由 @姜蕁 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 一個賬號可以綁定多個角色 /如果有些角色權限是互斥或者一樣的,那該賬號的用戶看的東西是求同存異嗎 ??

    來自浙江 回復
    1. 個人理解角色中有權限是互斥的,那么就應該在賬號分配的時候設計不能選擇互斥角色

      來自北京 回復
  2. 其實我還是想問一下,同一個頁面不同的角色進來看到的數據都是不一樣的(不是字段不同是可產看的數據范圍不同),如果要做成可配置化,應該怎么去做呢?有沒有哪位大佬可以解答一下呢,感謝!

    來自上海 回復
    1. 對于字段的數據范圍進行配置

      來自上海 回復
    2. 針對這個問題,你應該有相應的解決辦法了吧。我辦法是在添加用戶的時候給用戶進行分類,例如:總經理、主管、員工等。對應的賬戶可見范圍根據類型去進行限制加載。不知道你有沒有更好的實現方案,歡迎一起探討。

      來自廣東 回復
  3. 原來產品并沒有做賬號角色權限的劃分,后期想補上,請教下老數據該怎么處理呢?有什么好的思路嗎?

    來自北京 回復
  4. 大佬,我有個后臺設計私活,有興趣聊聊嗎

    來自日本 回復
    1. 還有這私活嗎,來,聊聊。

      來自四川 回復
  5. 深有同感,有些點我遇到過,有些點給了我擴展,超棒啊

    來自福建 回復
  6. 超級棒啊,最近剛剛接觸后臺,很有用的,想請教您一個細節,那個創建員工信息時,是把角色設置和基本信息分開錄入,如果我只填寫了員工信息,沒有選擇角色就點擊了保存,頁面回到列表頁還是繼續請求選擇角色?兩個板塊的信息是統一保存還是單獨保存,可不可以把選擇角色和基本信息放在一個板塊里呀?

    來自北京 回復
    1. 如果一個用戶只有一個角色,且后續不會變化,可以添加用戶信息的時候一起設定;但很多情況下,員工可能同時有多個角色,且可能會需要修改調整。所以,建議分成兩步,添加用戶信息一步,為用戶維護用戶角色是另外一步。

      來自上海 回復
  7. ?? 受用

    來自廣東 回復
  8. 賬號權限設定好之后,后期增加功能的時候,是分角色增加功能嗎?比如A角色增加abc功能,B角色增加cd功能??

    來自北京 回復
  9. 請問下第2點角色管理中的例子中,給角色添加權限,這里是不是只有頁面權限和數據權限,而沒體現操作權限呢?操作權限是不是頁面上的操作按鈕?

    來自北京 回復
    1. 權限配置應該還有一個單獨的頁面,分 頁面 功能 以及 數據,對下邊的子選項進行勾選。組合起來塑造一個角色

      來自浙江 回復
  10. 您好!希望加您微信多多交流

    來自四川 回復
  11. 您好!希望加您微信多多交流

    回復
  12. 請問數據權限后臺怎么控制的

    來自上海 回復
  13. 這是Axure原型么?

    來自四川 回復
    1. 對,是用axure畫的

      來自上海 回復
  14. 賬號、角色、權限用三個維度來定義用戶登陸后臺所擁有的權限。在真正操作時,是否會過于復雜。因為你要時時刻刻記住或記錄,對應的用戶所擁有的的角色與權限分別是什么。直接在用戶開通賬號選擇權限不好嗎?這樣直接開權限即可,不會出現權限互斥的問題。而且增加用戶新權限時,直接選擇對應權限即可。不用在去找文檔選擇對應角色或新增對應的角色。

    來自北京 回復
    1. 一般情況下,一個系統的權限會很多,一個賬號甚至可以登錄多個系統,如果每次創建賬戶的時候再一個個去勾選,其實是很不現實的。不過,如果權限比較少的情況下,你想要這樣設計也是可以的,沒有對錯的問題。

      來自上海 回復
    2. 極端一點的例子,你可以想象一下 如果今天新增初級用戶為5萬,兩種方案:
      1. 把初級用戶這個角色直接assign給所有新增用戶
      2. 手動給每個用戶去選擇權限

      我們肯定會選擇方案1呀,節省了太多時間和精力,

      來自北京 回復
    3. 這就是C與B的區別,B你不能先考慮操作是否復雜,而應該先考慮是否兼容多種場景,易于維護。

      來自上海 回復
    4. 經驗之談哈哈哈

      來自廣東 回復
    5. 看來這句是你的口頭禪了~

      來自香港 回復
  15. 一個賬號對應多個角色,當該用戶登錄系統時,A是一次性看到多個角色下的全部權限,B是通過切換角色的方式查看不同角色的不同權限。大家更多是采用哪種方案?

    來自福建 回復
    1. 肯定是A啊,B的意義何在?考慮什么限制嗎?

      來自北京 回復
    2. 一般來說都會先考慮A吧。

      來自上海 回復
    3. 我感覺要看這多個角色的數據權限范圍是否一致,如果一致那A是沒問題,如果不一致那應該是B。比如一個人即是部門A的負責人,又是分管財務的分管領導,作為部門負責人,他有部門所有事物的權限,可以訪問部門財務、認識、業務等數據,但是作為分管財務的飯館領導,那他能看整個單位的財務信息,但不能查看其它部門的人事、業務信息,如果合起來,就會是所有部門的所有財務、人事、業務都能拿看了。

      來自江蘇 回復
    4. 評論沒有編輯功能?發現錯別字都不能修改了。

      來自江蘇 回復
  16. 為部門角色規劃權限的事情,產品還是少/不去摻和,由運營人員去和對應的業務部去對接。個中緣由,一想就通。

    來自上海 回復
    1. 經驗之談

      來自北京 回復
  17. 很不錯,我現在的系統都是這樣設計的,基本上現在的后臺系統賬號權限設計都大同小異

    來自廣東 回復
    1. 是啊,最基本的元素都是那幾個

      來自上海 回復
    2. 簡單點的,賬號-角色-權限,如果權限比較多就賬號-角色-權限組-權限 ?? 我現在倆個系統就是這樣弄的

      來自廣東 回復
    3. 恩呢都差不多,我現在也是賬號——角色——權限:oops:

      來自上海 回復
  18. 很不錯,受教了 ??

    來自北京 回復
  19. 個人感覺,一個賬戶只有一個角色,一個角色可以有多個權限,而且還要考慮原始角色設計,即有一個角色擁有所有的權限,隨著系統功能的增加,權限自動增加,由它賦予其他角色新的權限或者建立角色

    來自山東 回復
    1. 一個賬戶擁有多個角色,是為了角色的權限統一化,如果一個賬戶只允許有一個角色的話,根據公司人員和業務需求不同,勢必會出現一大堆不標準化的“角色”,到后期對角色的管控是有很大風險的 ??

      來自北京 回復
  20. 很好 先收藏

    回復
  21. 基礎很牢,不知道,再往點的問題,如,,復雜的部門權限如何劃分,這種,你是怎么解決的

    回復
    1. 后面會再繼續整理完善的 ??

      來自上海 回復
  22. 正準備寫這個需求,涉及到總公司分公司幾十個用戶,8個角色,受教了。

    回復
    1. 一起學習進步

      來自上海 回復
  23. 梳理的很全面了!創建賬號時選擇角色應該屬必填項,如果過于復雜的業務其實并不適合

    回復
    1. 嗯嗯?,F在是基于工作中涉及到的項目整理的,后面會繼續思考學習,謝謝提示 ??

      來自上海 回復
  24. RBAC

    來自江蘇 回復
  25. 考慮是否需要提供賬號與賬號之間做數據關聯的入口。當然,這是屬于比較特殊的情況,當設計的控制數據權限的規則都不能滿足的時候,是否需要為特例提供操作入口;
    請教下 這句話 不是很理解 賬號和賬號之間怎么做數據關聯呢?是針對哪種用戶。

    來自海南 回復
    1. 其實我也不知道這樣表述正不正確。這句話想表達的意思是:比如某個部門所有人的默認權限是自己只能看到自己創建的數據,A只能看到他自己創建的,B也只能看到他自己創建的,若A也想要看到B的數據,那是不是可以把兩個賬號做關聯從而實現數據共享呢。

      來自上海 回復
    2. 這個地方的業務特點可能不應該屬于權限系統的范疇了吧,是否考慮可以通過業務操作來實現呢

      來自安徽 回復
    3. 有時候要根據實際情況做調整 這些也不是絕對的

      回復
    4. 千人千面

      來自江蘇 回復
  26. 很棒?。。?/p>

    來自海南 回復
  27. 想要轉發在我們公司內部平臺分享可以嗎

    來自山東 回復
  28. 我司的產品是從兩個層面去闡述的
    1.業務層面:用戶,崗位,部門
    2.系統層面:數據權限,功能權限
    用戶即是賬號,被賦予了崗位和部門
    崗位則是功能權限的集合,按照需求給崗位設置相對應的功能權限
    部門則是數據權限的集合,按照需求給部門設置相對應的數據權限

    簡單來說,崗位和部門結合為用戶;數據權限和功能權限結合為賬號權限

    來自廣東 回復
    1. 最近正好也在做這一塊,我的想法跟你的設計類似。想就此咨詢一下:
      1.你的意思是繞開了角色這一概念嗎?
      2.我也覺得這樣更符合公司組織架構或者更好理解,公司組織中,不同的崗位就擁有不同的權限,也就是說崗位就是系統上說的角色,然后把權限賦給崗位,崗位賦給用戶 是這樣嗎?
      3.部門就是數據權限的集合:那如果要給部門中的不同崗位賦予不同的數據權限要怎么辦呢?

      來自廣東 回復
    2. 不好意思,下午才看到你的信息
      1.角色即是崗位,概念一樣,稱呼不同而已。
      2.你的理解是正確的
      3.在系統層面,部門和崗位是獨立而平行的,也就是說,你可以任意組合部門和崗位之間的關系

      來自廣東 回復
    3. 謝謝你的回復~~ ??
      第三點我還不是很明白,對數據權限的理解我還不是很透徹 你會不會有什么指教給到我呢?

      來自廣東 回復
    4. 同一BU的設計和運營能看的數據肯定不完全相同,所以不用太死板地認為部門就決定數據權限。不過可取之處就是,角色可以從部門*崗位*職級3個小維度來做控制,決定到底哪些權限掛在下面。

      來自浙江 回復
    5. 那數據權限還是需要通過配置的方式來設置嗎?還是數據權限是通過什么方式來控制的呢?

      來自廣東 回復
    6. 如果具體場景,需要為同一個部門的不同人劃分數據權限的話,也可以做一個頁面來配置,只要確保數據集合能夠區分到一定的粒度。但是通常來說,通過部門(更應該說是組織架構,重點是節點間的關系)已經劃分了數據權限了,舉個OA的例子——工作日志,比如頂級部門A,子部門A1,子部門A2,那么A1可以看到A1部門下所有人的工作日志,A2可以看到A2部門下所有人的工作日志,A就可以看到A1,A2下的工作日志,這是不需要單獨配置的,組織架構已經確立了這種關系了,當然這里還會考慮限制數據可見的層級數的問題,根據具體需求來判斷了。

      來自山東 回復
    7. 明白了 非常謝謝 ??

      來自廣東 回復
  29. 寫得已經很全面了,本質是RBAC模型的實踐,經驗之談的部分很不錯,很多復雜的業務邏輯都考慮到了,很棒

    來自上海 回復
    1. 謝謝鼓勵

      來自上海 回復
  30. 非常感謝!正在準備案例,希望轉崗成功

    回復
    1. 加油,共同交流進步

      來自上海 回復