技術干貨 | 基于角色的菜單/按鈕級的統(tǒng)一權限管理

權限管理，一般指根據(jù)系統(tǒng)設置的安全規(guī)則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源，不多不少，而統(tǒng)一權限管理則是將分布在各個系統(tǒng)中的權限管理模塊統(tǒng)一規(guī)劃在一個系統(tǒng)中，由一個系統(tǒng)集中管控多個業(yè)務系統(tǒng)的權限相關信息。

目前很多企業(yè)應用系統(tǒng)數(shù)量較多，從幾個應用系統(tǒng)到十幾個甚至幾十個應用系統(tǒng)，各個應用系統(tǒng)獨立采購、獨立實施，缺少統(tǒng)一規(guī)劃，權限體系各不相同。

各自系統(tǒng)面向用戶群不同，有的面向全體員工，有的面向某個部門，有的面向某些崗位，用戶類型多樣。

各自系統(tǒng)權限體系獨立管理維護，各自為政，為日常的管理員授權、權限變更、清權帶來了不小的困擾，很多情況下，申請人不知道自己需要的權限，而管理員也不清楚申請人申請的權限是否達到權限最小化的要求，加之系統(tǒng)數(shù)量又多，結合到一起導致了企業(yè)里權限管理和使用混亂，很難梳理清楚、說得明白。

用戶在多個系統(tǒng)中都有賬號，但是卻無法直觀的快速地了解到用戶在企業(yè)中到底具備哪些系統(tǒng)權限，權限的高低也很難統(tǒng)計，用戶離職后賬號權限無法做到快速清權，往往人員離職半年后此人的管理員賬號依然可以使用，帶來了很多安全隱患。

一般會將權限體系分為如下幾種：

大門級權限管理

顧名思義，只做大門級的權限控制，至于用戶在應用系統(tǒng)大門內(nèi)有什么樣的權限，完全由應用系統(tǒng)自己控制管理。

這種控制是最粗粒度的控制了，好在比較容易集成、推廣。

角色級權限控制

通過集中管理各個系統(tǒng)中的角色，結合統(tǒng)一用戶管理，可實現(xiàn)用戶在各個系統(tǒng)中的角色級權限的統(tǒng)一管控。

而每個角色在各個系統(tǒng)中具備的權限則是由應用系統(tǒng)完全獨立的控制管理。

菜單級的權限控制

統(tǒng)一授權模塊管理維護一套應用系統(tǒng)的菜單、按鈕，通過角色與菜單的映射，集中管理多個系統(tǒng)的角色-菜單權限。

操作級的權限控制

在菜單級權限控制的基礎上，將頁面上的操作動作也一并管理維護，即頁面上的操作按鈕，簡單說就是增、刪、改、查等操作的統(tǒng)一授權管理，此種管理模式，可將權限控制得更加細致、準確。

數(shù)據(jù)級權限控制

數(shù)據(jù)級的權限控制更多的則是業(yè)務場景相關，不會考慮統(tǒng)一集中管控，一般是通過部門、崗位等人員屬性條件進行統(tǒng)一管理維護，真正的權限控制策略，則是由應用系統(tǒng)去把控，例如用戶崗位是財務經(jīng)理，則可以看到財務系統(tǒng)中的全部數(shù)據(jù)，而財務部門的其他人員則看到部分數(shù)據(jù)。在此場景下，統(tǒng)一身份管理授權的數(shù)據(jù)級權限則轉變?yōu)橛脩羯矸莨芾淼母鞣N身份信息的管理維護。

我們今天要分享的則是一例基于角色的菜單、按鈕級別的統(tǒng)一權限管理案例。

案例背景

要做到細粒度權限的統(tǒng)一管控，由于涉及各個應用系統(tǒng)的權限梳理、集成改造，須要應用系統(tǒng)給予大力的支持，以及上級大領導的強力推動，否則很難有比較明顯的成果。

而此案例的大背景則是政府行業(yè)，信息化建設統(tǒng)一規(guī)劃，將一批新建系統(tǒng)統(tǒng)一整合，在此契機下，應用系統(tǒng)可以很好地配合權限統(tǒng)一管控體系的建設。

權限核心要素

統(tǒng)一權限須要從幾個維度維護管理權限相關的信息：

1、用戶身份信息

身份信息的維護管理根據(jù)實際場景主要分為兩類：

? 已有身份源系統(tǒng)，例如HR系統(tǒng)

將身份源系統(tǒng)中的身份信息同步到權限管理系統(tǒng)中，并做定時或實時的數(shù)據(jù)同步集成。

? 無身份源系統(tǒng)

在權限管理系統(tǒng)中維護管理用戶的身份信息，將權限管理系統(tǒng)作為身份數(shù)據(jù)源。

2、應用系統(tǒng)維護

須要將管理的應用系統(tǒng)注冊到統(tǒng)一權限管理平臺中，注冊時會生成認證、鑒權相關的唯一標識。

3、角色維護

維護管理各個應用系統(tǒng)中的角色列表，由于將來的管理模式是由統(tǒng)一權限管理平臺來管控權限，所以應用系統(tǒng)無須在自己系統(tǒng)中管理角色信息。

4、菜單、按鈕維護

維護管理各個應用系統(tǒng)中的菜單、按鈕列表，須要與應用系統(tǒng)中的菜單和按鈕對應。

授權關系

在統(tǒng)一授權平臺中維護管理如下授權關系：

1、系統(tǒng)角色對應系統(tǒng)菜單/按鈕的權限定義

2、應用系統(tǒng)與系統(tǒng)角色的對應關系

3、用戶與應用系統(tǒng)角色的授權關系

統(tǒng)一認證、鑒權邏輯

統(tǒng)一認證鑒權主要包含如下三個環(huán)節(jié)：

1、門戶系統(tǒng)的登錄

門戶系統(tǒng)的認證與其他應用系統(tǒng)的邏輯一致，在此場景中是為了更好地體現(xiàn)出統(tǒng)一認證的效果，所以把門戶的認證單獨描述。

2、應用系統(tǒng)的認證

第一次訪問應用系統(tǒng)鏈接時，須要進行此邏輯的交互認證。

3、鑒權邏輯

登錄完成后，再訪問的所有菜單/按鈕都須要有應用系統(tǒng)服務器端的鑒權邏輯，避免越權操作。

(1)用戶訪問門戶系統(tǒng)，跳轉至認證中心認證。

(2)用戶在認證中心頁面登錄，輸入正確的用戶名密碼。

(3)認證成功后，進入門戶系統(tǒng)頁面。

(4)用戶在門戶頁面點擊應用系統(tǒng)的鏈接，請求流轉至應用系統(tǒng)。

(5)應用系統(tǒng)攔截器判斷沒有session，向認證中心發(fā)起認證“請求code臨時票據(jù)”，請求方式為瀏覽器重定向。

(6)應用系統(tǒng)根據(jù)瀏覽器返回的code參數(shù)，通過服務器間的API請求獲取“access_token”，避免使用瀏覽器方式請求。

(7)應用系統(tǒng)根據(jù)access_token請求認證中心，獲取用戶信息和權限信息（角色列表、菜單/按鈕列表），成功后，進入系統(tǒng)，展現(xiàn)菜單/按鈕。

(8)用戶點擊某個菜單/按鈕時，應用系統(tǒng)后臺須要到認證中心鑒權，根據(jù)access_token和應用標識、菜單/按鈕編號請求鑒權接口，判斷用戶是否有權限訪問此菜單/按鈕。

(9)根據(jù)鑒權結果判斷是否允許用戶訪問此菜單。

主要難點

● 統(tǒng)一標準規(guī)范的制定。

● 下游多個業(yè)務系統(tǒng)須要按照制定的權限管理標準進行集成改造。

● 為達到效果，業(yè)務系統(tǒng)是否按照標準確實落實，須要監(jiān)督。

業(yè)務價值

● 統(tǒng)一了業(yè)務系統(tǒng)權限管理，集中管理業(yè)務系統(tǒng)的權限。

● 提供統(tǒng)一權限視圖，可方便快捷的查看用戶的全局權限。

● 規(guī)范了業(yè)務系統(tǒng)的權限管理，提高系統(tǒng)權限管理規(guī)范性。

● 提供全局鑒權體系，防止越權操作。

● 提供訪問審計，集中審計用戶在多個系統(tǒng)中的操作行為。