權限管理系統設計過程

今天和大家一起探討權限管理方面的設計心得。權限管理,是B端后臺系統一個重要的組成部分,屬于底層的支撐功能,系統內所有的功能,甚至字段的增減都涉及到權限的分配和管理。因此怎樣配置后臺的權限系統,以適應多變業務需求,是今天筆者和大家分享的內容。

文章目錄

  • 控制權限的主體
  • 權限管理模型
    • 通過角色控制賬號權限
    • 通過簡檔控制賬號權限
  • 權限管理的分類
    • 菜單權限
    • 操作權限
    • 數據權限

一、控制權限的主體

后臺系統是通過賬號登錄的,賬號用戶控制每個員工的權限。

二、權限管理模型

  1. 通過角色控制賬號權限
    除非后臺賬號數量很少(20個以內),,否則一般不會直接對賬號配置權限,因為用戶基數比較大的情況下,很多人的權限都是一樣的,如果管理員給100人甚至更多授權,工作量巨大,因此引入了“角色”的概念。一個角色可以與多個用戶關聯,管理員只需要把該角色賦予用戶,那么用戶就有了該角色下的所有權限。角色起到了橋梁的作用,這樣設計提升了效率。這種權限管理的設計模型如下,一個賬號可以對應多個角色,每個角色對應不同的權限。


    角色-權限管理模型
  1. 通過簡檔控制賬號權限
    一些大型的公司,用戶數量較大,不同部門下的角色,權限是一樣的,比如英國部下的銷售人員和美國部下的銷售人員權限一致,如果每個新增一個功能,所有角色都需要修改權限,那么對于管理員來說,維護成本巨大,因此可以引入簡檔的概念。筆者所在的公司,后臺賬號大約有500個,角色有80多個,簡檔僅有10個,權限變更時,只需要修改這10個簡檔就可以了,效率非常高。這種權限管理的設計模型如下,一個賬號對應一個簡檔,每個簡檔對應不同的權限。這種模型還有一個好處就是,可以利用上下級的角色關系,控制數據的權限,這方面在下面詳細說。


    簡檔-權限管理模型
  2. 通過賬號、角色、簡檔都可以實現系統權限的控制,沒有說哪種方式是最好的,如果公司少于100人,角色不多,完全沒有必要采用簡檔控制權限的方式,關鍵是根據自己公司的業務特點選擇最合適的方案。

三、權限管理的分類

上面說到的是控制權限的媒介,下面重點講解權限管理都包含哪些內容,應該怎樣進行設計。

  1. 菜單權限
    即用戶在系統中可以看到的頁面,由菜單來控制,菜單包括一級菜單、二級菜單,只要用戶有一級和二級菜單的權限,那么用戶就可以訪問頁面。如圖所示,即對應該角色/簡檔的用戶對于分銷管理、運營管理等在菜單欄沒有入口。


    菜單權限配置
  1. 操作權限
    1. 操作權限分為對對象的操作權限和對字段的操作權限。對象的操作權限包括查看,創建,編輯、刪除。用戶點擊刪除按鈕時,后臺會校驗用戶角色下的所有權限是否包含該刪除權限,如果是,就可以進行下一步操作,反之提示無權限。如圖所示,即對應這個角色/簡檔的賬號對接送機訂單僅有查看的權限,沒有創建、編輯和刪除的權限。


      對象操作權限配置
    2. 字段權限是指對記錄對應屬性的操作權限,字段的操作權限一般有2種,可查看權限和可編輯權限。配置了可查看全看,即用戶可以查看該字段,沒有配置該權限的賬號,不能在頁面上看到該字段。配置了可編權限的賬號,可以編輯該字段的屬性。如圖所示,對應該角色/簡檔的用戶只可以查看該對象的客戶字段,不能對客戶進行修改。


      字段操作權限配置
  1. 數據權限
    1. 通過角色/簡檔控制數據的查看和編輯權限: 數據權限是指每個賬號可查看的數據是不同的,可以通過角色/簡檔配置對不同對象的數據全新,這種設計方式上面的操作權限已經詳細介紹過。
    2. 通過對象控制公用權限和專用權限: 在新建對象時,可以設置對象的公用權限和專用權限,公用權限是指該對象下的記錄,所有賬號都可以訪問。專用權限是指只有創建人可以查看記錄,其他人沒有權限查看。
    3. 通過角色控制上下級數據權限: 在實際的場景中,上級往往需要查看下級的數據,設置數據的專用性無法滿足該需求。比如美國部銷售總監需要看到其部門下的用戶數據,英國部銷售總監需要看到英國部下的用戶數據。解決方案是通過角色判斷賬號間的上下級關系,上級可以查看下級的角色。這也是通過簡檔而不通角色關聯權限的好處,因為通過賬號關聯角色,再通過角色關聯賬號的話,賬號和角色間一般是多對多的關系,這樣就無法分辨賬號間的上下級。通過賬號關聯簡檔,簡檔關聯權限,可以保證一個賬號只有一個角色,從而可以判斷出賬號間的上下級關系。
    4. 通過共享規則控制數據權限: 有些情況,賬號需要查看某個對象下的一些記錄,但是該賬號和創建記錄的賬號在組織架構上沒有上下級關系,比如美國財務部需要查看美國銷售部下的訂單數據,同時為了數據的安全性,不能給美國財務部的賬號查所有業務部門的訂單數據。這時就需要用到共享規則。共享規則的本質是把符合一定條件的記錄共享給一些賬號,共享后這些賬號可以查看或者編輯這些數據。共享規則的配置,需要確定以下四要素:
      1. 共享的對象:確定共享的是哪個對象的數據。
      2. 共享數據的條件:確定該對象下的哪些數據需要共享。
      3. 共享的賬號:確定這些數據需要貢獻給哪些賬號。
      4. 共享權限:確定共享后,賬號對這些數據的權限,分為只讀和編輯權限。

總結:今天和大家探討了權限設計的2種模型和權限設計包含內容。大家可以結合公司的特點,選擇合適的設計方法。在實際項目中,會遇到多個系統,多個用戶類型,多個使用場景,這就需要具體問題具體分析,但最核心都離不開這些方法,我們可以在其基礎上進行擴展來滿足需求。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,363評論 6 532
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,497評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 176,305評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,962評論 1 311
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,727評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,193評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,257評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,411評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,945評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,777評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,978評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,519評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,216評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,642評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,878評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,657評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,960評論 2 373

推薦閱讀更多精彩內容