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

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

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

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

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

一般會將權(quán)限體系分為如下幾種：

大門級權(quán)限管理

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

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

角色級權(quán)限控制

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

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

菜單級的權(quán)限控制

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

操作級的權(quán)限控制

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

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

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

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

案例背景

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

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

權(quán)限核心要素

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

1、用戶身份信息

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

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

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

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

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

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

須要將管理的應(yīng)用系統(tǒng)注冊到統(tǒng)一權(quán)限管理平臺中，注冊時會生成認證、鑒權(quán)相關(guān)的標(biāo)識。

3、角色維護

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

4、菜單、按鈕維護

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

關(guān)系

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

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

2、應(yīng)用系統(tǒng)與系統(tǒng)角色的對應(yīng)關(guān)系

3、用戶與應(yīng)用系統(tǒng)角色的關(guān)系

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

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

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

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

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

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

3、鑒權(quán)邏輯

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

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

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

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

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

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

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

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

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

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

主要難點

● 統(tǒng)一標(biāo)準(zhǔn)規(guī)范的制定。

● 下游多個業(yè)務(wù)系統(tǒng)須要按照制定的權(quán)限管理標(biāo)準(zhǔn)進行集成改造。

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

業(yè)務(wù)價值

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

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

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

● 提供全局鑒權(quán)體系，防止越權(quán)操作。

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