后臺系統:賬號權限系統設計
文章對賬號權限系統設計展開分析,希望能夠給你帶來些啟發。
一、系統概述
一個賬號權限管理系統,主要包括三個元素:賬號、角色、權限。我們所要管理的,也就是賬號、角色和權限之間的關系。
賬號:基本上所有的應用,無論是移動端,PC端,C端或B端產品,登陸都需要一個賬號。只是對于C端的產品,都是用戶自己注冊即可。而對于后臺產品而言,是需要公司內部人員去創建賬號的。
角色:所謂角色,就是用來控制各個賬號的操作范圍的,可以理解為權限組。因為一個系統中權限太多,我們不可能每創建一個賬號,就去挨個設置一遍權限,因此可以根據不同的部門、職級、工作內容等來對權限進行分組,制定成不同的角色,這樣,在創建賬號時,就可以直接賦予賬號不同的角色,從而把角色擁有的權限給到這個賬號。
權限:包括數據權限、操作權限和頁面權限。
一、數據權限:即賬號可以看到的數據范圍,比如一個旅游行業的公司管理者能看到公司的所有數據,而亞太部的人只能看到亞太部門產生的數據。在設計過程中,數據權限控制的難易程度與業務和公司部門設置的復雜程度有關。
二、頁面權限&操作權限:頁面權限即賬號可以看到的頁面內容,操作權限即用戶可以進行操作的內容,如增刪改等。在產品設計的過程中,可以將操作權限和頁面權限結合起來做到一個集合中,創建角色時將權限賦予給角色即可。
系統的主要流程為:將權限設置成不同的集合,即角色,再將角色綁定到賬號上,那么這個賬號就擁有了這些角色的權限集合。一個賬號可以綁定多個角色,一個角色又擁有多個權限。
如上圖所示:用戶A擁有了角色1和角色2兩個角色,從而擁有了“增加、刪除、審核”的權限。
二、實例設計
1、賬號管理
添加/編輯賬號:
在創建賬號時,一般都需要填寫基本信息和設置角色?;拘畔⒅饕ㄐ彰?,部門,賬號備注等等,不同企業需求不同。
此外,為了控制數據權限,還可能會有賬號等級的選擇、賬號關聯、上下級關系綁定等操作。具體流程視設計情況而定。
2、角色管理
添加/編輯角色:
需要說明的是,角色不能隨意刪除或禁用,需要判定該角色有沒有被哪個賬號綁定,若該角色正在被使用,則不允許刪除并給出相應的提示。
三、經驗之談
1、事先可以對賬號進行一個等級劃分(根據實際業務制定劃分規則),然后可以根據等級來判定數據權限。如等級為公司高級管理者,則可以看到所有的數據,而等級為分公司管理員,則根據分公司的ID或者名稱去獲取對應的數據等。不過這個只能做一個比較粗略的控制,僅一個等級來控制數據權限是遠遠不夠的;
2、考慮是否需要提供賬號與賬號之間做數據關聯的入口。當然,這是屬于比較特殊的情況,當設計的控制數據權限的規則都不能滿足的時候,是否需要為特例提供操作入口;
3、考慮是否需要提供一個賬號和數據之間直接做綁定的入口?如:等級為分公司管理員,由于業務需求,需要看到另外一個分公司的某條數據,該如何實現。當然,這里只是舉了一個很簡單的例子,實際實現時會有很多更細節和深入的問題;
4、若大部分賬號在權限上都存在差異,那是否每個賬號都需要有一個設置詳細權限的地方,而僅把角色當做一個快捷選擇的方式。(若不是必需,最好不要采取該種方式,這樣會破壞權限的規范性,不利于維護和管理);
5、創建角色(權限組)之前,需要明確各個部門之間的業務范圍及權限(包括頁面權限和操作權限),并將這些人就行劃分;當然,隨著公司的業務和后臺系統功能的改變,各個角色的權限是需要不斷完善和調整的;
6、在一些系統流程中,還需要為權限設置互斥關系,這樣的話,擁有互斥權限的兩個角色就不能同時綁定給同一個賬號了。是否需要這一步操作,需要根據業務情況而定;
7、對于一些基礎的賬號,在創建賬號時,是否需要直接根據賬號等級綁定默認角色(即給以默認權限)。
暫時想到的就是這些,后面想到了會再繼續補充。
小小產品一枚,文章純屬工作中個人經驗總結,歡迎大神拍磚指教。
本文由 @姜蕁 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
一個賬號可以綁定多個角色 /如果有些角色權限是互斥或者一樣的,那該賬號的用戶看的東西是求同存異嗎 ??
個人理解角色中有權限是互斥的,那么就應該在賬號分配的時候設計不能選擇互斥角色
其實我還是想問一下,同一個頁面不同的角色進來看到的數據都是不一樣的(不是字段不同是可產看的數據范圍不同),如果要做成可配置化,應該怎么去做呢?有沒有哪位大佬可以解答一下呢,感謝!
對于字段的數據范圍進行配置
針對這個問題,你應該有相應的解決辦法了吧。我辦法是在添加用戶的時候給用戶進行分類,例如:總經理、主管、員工等。對應的賬戶可見范圍根據類型去進行限制加載。不知道你有沒有更好的實現方案,歡迎一起探討。
原來產品并沒有做賬號角色權限的劃分,后期想補上,請教下老數據該怎么處理呢?有什么好的思路嗎?
大佬,我有個后臺設計私活,有興趣聊聊嗎
還有這私活嗎,來,聊聊。
深有同感,有些點我遇到過,有些點給了我擴展,超棒啊
超級棒啊,最近剛剛接觸后臺,很有用的,想請教您一個細節,那個創建員工信息時,是把角色設置和基本信息分開錄入,如果我只填寫了員工信息,沒有選擇角色就點擊了保存,頁面回到列表頁還是繼續請求選擇角色?兩個板塊的信息是統一保存還是單獨保存,可不可以把選擇角色和基本信息放在一個板塊里呀?
如果一個用戶只有一個角色,且后續不會變化,可以添加用戶信息的時候一起設定;但很多情況下,員工可能同時有多個角色,且可能會需要修改調整。所以,建議分成兩步,添加用戶信息一步,為用戶維護用戶角色是另外一步。
?? 受用
賬號權限設定好之后,后期增加功能的時候,是分角色增加功能嗎?比如A角色增加abc功能,B角色增加cd功能??
請問下第2點角色管理中的例子中,給角色添加權限,這里是不是只有頁面權限和數據權限,而沒體現操作權限呢?操作權限是不是頁面上的操作按鈕?
權限配置應該還有一個單獨的頁面,分 頁面 功能 以及 數據,對下邊的子選項進行勾選。組合起來塑造一個角色
您好!希望加您微信多多交流
您好!希望加您微信多多交流
請問數據權限后臺怎么控制的
這是Axure原型么?
對,是用axure畫的
賬號、角色、權限用三個維度來定義用戶登陸后臺所擁有的權限。在真正操作時,是否會過于復雜。因為你要時時刻刻記住或記錄,對應的用戶所擁有的的角色與權限分別是什么。直接在用戶開通賬號選擇權限不好嗎?這樣直接開權限即可,不會出現權限互斥的問題。而且增加用戶新權限時,直接選擇對應權限即可。不用在去找文檔選擇對應角色或新增對應的角色。
一般情況下,一個系統的權限會很多,一個賬號甚至可以登錄多個系統,如果每次創建賬戶的時候再一個個去勾選,其實是很不現實的。不過,如果權限比較少的情況下,你想要這樣設計也是可以的,沒有對錯的問題。
極端一點的例子,你可以想象一下 如果今天新增初級用戶為5萬,兩種方案:
1. 把初級用戶這個角色直接assign給所有新增用戶
2. 手動給每個用戶去選擇權限
我們肯定會選擇方案1呀,節省了太多時間和精力,
這就是C與B的區別,B你不能先考慮操作是否復雜,而應該先考慮是否兼容多種場景,易于維護。
經驗之談哈哈哈
看來這句是你的口頭禪了~
一個賬號對應多個角色,當該用戶登錄系統時,A是一次性看到多個角色下的全部權限,B是通過切換角色的方式查看不同角色的不同權限。大家更多是采用哪種方案?
肯定是A啊,B的意義何在?考慮什么限制嗎?
一般來說都會先考慮A吧。
我感覺要看這多個角色的數據權限范圍是否一致,如果一致那A是沒問題,如果不一致那應該是B。比如一個人即是部門A的負責人,又是分管財務的分管領導,作為部門負責人,他有部門所有事物的權限,可以訪問部門財務、認識、業務等數據,但是作為分管財務的飯館領導,那他能看整個單位的財務信息,但不能查看其它部門的人事、業務信息,如果合起來,就會是所有部門的所有財務、人事、業務都能拿看了。
評論沒有編輯功能?發現錯別字都不能修改了。
為部門角色規劃權限的事情,產品還是少/不去摻和,由運營人員去和對應的業務部去對接。個中緣由,一想就通。
經驗之談
很不錯,我現在的系統都是這樣設計的,基本上現在的后臺系統賬號權限設計都大同小異
是啊,最基本的元素都是那幾個
簡單點的,賬號-角色-權限,如果權限比較多就賬號-角色-權限組-權限 ?? 我現在倆個系統就是這樣弄的
恩呢都差不多,我現在也是賬號——角色——權限:oops:
很不錯,受教了 ??
個人感覺,一個賬戶只有一個角色,一個角色可以有多個權限,而且還要考慮原始角色設計,即有一個角色擁有所有的權限,隨著系統功能的增加,權限自動增加,由它賦予其他角色新的權限或者建立角色
一個賬戶擁有多個角色,是為了角色的權限統一化,如果一個賬戶只允許有一個角色的話,根據公司人員和業務需求不同,勢必會出現一大堆不標準化的“角色”,到后期對角色的管控是有很大風險的 ??
很好 先收藏
基礎很牢,不知道,再往點的問題,如,,復雜的部門權限如何劃分,這種,你是怎么解決的
后面會再繼續整理完善的 ??
正準備寫這個需求,涉及到總公司分公司幾十個用戶,8個角色,受教了。
一起學習進步
梳理的很全面了!創建賬號時選擇角色應該屬必填項,如果過于復雜的業務其實并不適合
嗯嗯?,F在是基于工作中涉及到的項目整理的,后面會繼續思考學習,謝謝提示 ??
RBAC
考慮是否需要提供賬號與賬號之間做數據關聯的入口。當然,這是屬于比較特殊的情況,當設計的控制數據權限的規則都不能滿足的時候,是否需要為特例提供操作入口;
請教下 這句話 不是很理解 賬號和賬號之間怎么做數據關聯呢?是針對哪種用戶。
其實我也不知道這樣表述正不正確。這句話想表達的意思是:比如某個部門所有人的默認權限是自己只能看到自己創建的數據,A只能看到他自己創建的,B也只能看到他自己創建的,若A也想要看到B的數據,那是不是可以把兩個賬號做關聯從而實現數據共享呢。
這個地方的業務特點可能不應該屬于權限系統的范疇了吧,是否考慮可以通過業務操作來實現呢
有時候要根據實際情況做調整 這些也不是絕對的
千人千面
很棒?。。?/p>
想要轉發在我們公司內部平臺分享可以嗎
我司的產品是從兩個層面去闡述的
1.業務層面:用戶,崗位,部門
2.系統層面:數據權限,功能權限
用戶即是賬號,被賦予了崗位和部門
崗位則是功能權限的集合,按照需求給崗位設置相對應的功能權限
部門則是數據權限的集合,按照需求給部門設置相對應的數據權限
簡單來說,崗位和部門結合為用戶;數據權限和功能權限結合為賬號權限
最近正好也在做這一塊,我的想法跟你的設計類似。想就此咨詢一下:
1.你的意思是繞開了角色這一概念嗎?
2.我也覺得這樣更符合公司組織架構或者更好理解,公司組織中,不同的崗位就擁有不同的權限,也就是說崗位就是系統上說的角色,然后把權限賦給崗位,崗位賦給用戶 是這樣嗎?
3.部門就是數據權限的集合:那如果要給部門中的不同崗位賦予不同的數據權限要怎么辦呢?
不好意思,下午才看到你的信息
1.角色即是崗位,概念一樣,稱呼不同而已。
2.你的理解是正確的
3.在系統層面,部門和崗位是獨立而平行的,也就是說,你可以任意組合部門和崗位之間的關系
謝謝你的回復~~ ??
第三點我還不是很明白,對數據權限的理解我還不是很透徹 你會不會有什么指教給到我呢?
同一BU的設計和運營能看的數據肯定不完全相同,所以不用太死板地認為部門就決定數據權限。不過可取之處就是,角色可以從部門*崗位*職級3個小維度來做控制,決定到底哪些權限掛在下面。
那數據權限還是需要通過配置的方式來設置嗎?還是數據權限是通過什么方式來控制的呢?
如果具體場景,需要為同一個部門的不同人劃分數據權限的話,也可以做一個頁面來配置,只要確保數據集合能夠區分到一定的粒度。但是通常來說,通過部門(更應該說是組織架構,重點是節點間的關系)已經劃分了數據權限了,舉個OA的例子——工作日志,比如頂級部門A,子部門A1,子部門A2,那么A1可以看到A1部門下所有人的工作日志,A2可以看到A2部門下所有人的工作日志,A就可以看到A1,A2下的工作日志,這是不需要單獨配置的,組織架構已經確立了這種關系了,當然這里還會考慮限制數據可見的層級數的問題,根據具體需求來判斷了。
明白了 非常謝謝 ??
寫得已經很全面了,本質是RBAC模型的實踐,經驗之談的部分很不錯,很多復雜的業務邏輯都考慮到了,很棒
謝謝鼓勵
非常感謝!正在準備案例,希望轉崗成功
加油,共同交流進步