分布式架構(gòu)下權(quán)限控制系統(tǒng)的設(shè)計與優(yōu)化*

雷云祥，蔣其海，田 杰，段明秀

(吉首大學(xué)計算機科學(xué)與工程學(xué)院，湖南 吉首 416000)

在常見的分布式系統(tǒng)架構(gòu)中，一般在每臺服務(wù)器上都獨立部署一套完整的權(quán)限系統(tǒng)，這樣的架構(gòu)會導(dǎo)致系統(tǒng)的維護成本偏高且效率低下.雖然基于Session的單點登錄系統(tǒng)[1]在整個集群中只有唯一的一臺權(quán)限控制服務(wù)器，但是通過身份驗證的用戶訪問集群中的數(shù)據(jù)資源時，需要先在權(quán)限控制服務(wù)器進行鑒權(quán)，然后才能訪問相應(yīng)的數(shù)據(jù)資源.這樣操作雖然實現(xiàn)了權(quán)限控制的相對獨立，但向集群的所有數(shù)據(jù)請求都要先訪問權(quán)限控制服務(wù)器，導(dǎo)致系統(tǒng)響應(yīng)的實時性降低，而且當(dāng)權(quán)限控制服務(wù)器死機時，整個集群將處于癱瘓狀態(tài).針對上述認(rèn)證方式暴露的性能和效率低等問題，筆者擬在JSON網(wǎng)絡(luò)令牌(JSON Web Token，JWT)技術(shù)的基礎(chǔ)上通過自定義鑒權(quán)技術(shù)，將身份認(rèn)證獨立為認(rèn)證服務(wù)器以實現(xiàn)用戶身份的統(tǒng)一認(rèn)證，并將用戶鑒權(quán)分散到各個業(yè)務(wù)服務(wù)器以實現(xiàn)對數(shù)據(jù)請求的鑒權(quán)，即采用“集中認(rèn)證，分散鑒權(quán)”模式，以期滿足大部分系統(tǒng)在分布式環(huán)境下對權(quán)限管理的需要.

1 關(guān)鍵技術(shù)

1.1 JWT

JWT是一種用于Web環(huán)境下各方之間傳遞信息的表述性聲明規(guī)范，它定義了一種簡潔的、自包含的方法，用于通信雙方以JSON對象的形式安全地傳遞信息.JWT由Header頭部、Payload載荷和Signature簽名3個部分組成.載荷主要用來在不同服務(wù)器之間交互信息，它由默認(rèn)預(yù)定義信息和自定義信息組成：默認(rèn)預(yù)定義信息包括簽發(fā)時間、過期時間等；自定義信息是業(yè)務(wù)處理中需要用到的信息，如用戶賬號信息和權(quán)限信息等.簽名由Header、私鑰和Payload組合加密生成，它實際上是一個加密字符串，其中私鑰由創(chuàng)建Token的服務(wù)器提供.簽名的作用是，當(dāng)服務(wù)器接收Token后，通過拿取Header和Payload信息，再組合服務(wù)器本身的私鑰生成一個新的簽名，將新的簽名和Token中的簽名進行比對，查看是否一致，從而驗證Token是否被篡改.

基于JWT技術(shù)的認(rèn)證流程是，通過身份認(rèn)證的用戶將獲取的Token存儲在客戶端，當(dāng)客戶端每次請求服務(wù)器資源時，在請求頭中攜帶Token，供服務(wù)器實現(xiàn)鑒權(quán)[2].

1.2 Spring Security

Spring Security是一個安全性框架，能夠與SpringBoot和Mybatis等各大框架集成使用.Spring Security提供了默認(rèn)的十幾種過濾器，每一種過濾器都能繼承自定義實現(xiàn)，如“UsernamePasswordAuthenticationFilter”主要用來實現(xiàn)登錄認(rèn)證功能.權(quán)限系統(tǒng)關(guān)于安全方面的2個核心功能是認(rèn)證和鑒權(quán)：認(rèn)證是對用戶進行身份驗證，判斷用戶是否為系統(tǒng)合法用戶；鑒權(quán)是當(dāng)用戶發(fā)起對資源的訪問時，服務(wù)器判斷用戶是否具備訪問請求該資源的權(quán)限[3].

2 問題分析

2.1 認(rèn)證信息存儲問題

對于單體架構(gòu)系統(tǒng)，認(rèn)證成功后，認(rèn)證信息可以直接存儲到本地服務(wù)器.對于分布式集群系統(tǒng)，由于負(fù)載均衡服務(wù)器將請求分發(fā)到集群中的任何一臺服務(wù)器上，因此要保證每臺服務(wù)器鑒權(quán)時能夠拿到正確的認(rèn)證信息，就不要采用Session認(rèn)證技術(shù)，否則會導(dǎo)致服務(wù)器性能降低.為了解決這個問題，可以將用戶身份信息和權(quán)限信息置于Token中，由客戶端存儲該Token，而服務(wù)器端無需存儲用戶認(rèn)證信息或會話信息，以減輕服務(wù)端的壓力.

2.2 分布式集群鑒權(quán)問題

分布式集群環(huán)境下通過一臺鑒權(quán)服務(wù)器進行集中鑒權(quán)，勢必會導(dǎo)致鑒權(quán)服務(wù)器訪問壓力大，且當(dāng)訪問不需要鑒權(quán)的服務(wù)器時，依然要經(jīng)過鑒權(quán)服務(wù)器的路由轉(zhuǎn)發(fā)，增加服務(wù)響應(yīng)時間.

動態(tài)權(quán)限管理系統(tǒng)[4]采用JWT技術(shù)，將認(rèn)證后的賬號信息存放到Token中，通過在請求中攜帶Token訪問服務(wù)器實現(xiàn)分散鑒權(quán).但Token中并未存放權(quán)限信息，每次鑒權(quán)需要通過查詢數(shù)據(jù)庫獲取用戶的權(quán)限信息，造成資源浪費和性能下降.為了解決這個問題，可以采用“分散鑒權(quán)”模式：一方面，將鑒權(quán)過程分散到各個服務(wù)器，當(dāng)認(rèn)證成功后，將權(quán)限信息存儲在Token中，鑒權(quán)時直接從Token中獲得權(quán)限信息，從而避免頻繁地訪問數(shù)據(jù)庫；另一方面，對于不需要鑒權(quán)的服務(wù)器，就直接去除鑒權(quán)模塊.

2.3 Token過期問題

JWT簽發(fā)時，在它的載荷部分存放了Token的簽發(fā)時間和過期時間，為了防止Token被盜造成嚴(yán)重的后果，Token的有效時間一般設(shè)置得很短.這樣會造成Token頻繁失效，用戶需要不斷重復(fù)登錄，從而大大降低了用戶體驗.為了解決這個問題，可以通過引入基于Refresh Token的靜默刷新機制進行Token刷新，在Token失效之前獲取新的Token，解決了用戶頻繁掉線問題.

3 系統(tǒng)方案設(shè)計

3.1 架構(gòu)設(shè)計

分布式權(quán)限管理系統(tǒng)架構(gòu)如圖1所示.系統(tǒng)通過Nginx進行反向代理，將用戶的請求路由到不同的服務(wù)器，認(rèn)證模塊單獨拿出，并將用戶認(rèn)證獲取Token放到認(rèn)證服務(wù)器，每一個Web應(yīng)用服務(wù)器都有自定義的權(quán)限鑒權(quán)模塊.

圖1 分布式權(quán)限管理系統(tǒng)架構(gòu)

3.2 認(rèn)證流程

用戶進行身份認(rèn)證的流程如圖2所示.

圖2 認(rèn)證流程

認(rèn)證具體步驟如下：

(ⅰ)用戶發(fā)送登錄請求到認(rèn)證服務(wù)器.

(ⅱ)認(rèn)證服務(wù)器攔截請求，進行用戶身份驗證，驗證成功則轉(zhuǎn)至(ⅲ)，驗證失敗則將登錄失敗信息返回給前端.

(ⅲ)查詢用戶所有資源信息(角色、接口權(quán)限等)，按照權(quán)限信息生成算法將擁有的所有應(yīng)用程序編程(Application Programming Interface，API)接口權(quán)限生成為權(quán)限集合，同時用通用唯一識別碼(Universally Unique Identifier，UUID)作為Key，將用戶的權(quán)限集合儲存在Redis，用于之后的權(quán)限刷新.

(ⅳ)通過權(quán)限集合和用戶賬號等信息生成Access Token，通過用戶賬號和權(quán)限集合對應(yīng)的UUID等信息生成Refresh Token，2個Token的簽發(fā)時間和過期時間一致.

(ⅴ)將認(rèn)證信息返回給客戶端，客戶端將2個Token存儲在本地.

3.3 鑒權(quán)流程

服務(wù)器鑒權(quán)功能主要由自定義的過濾器實現(xiàn)，過濾器對客戶端的請求進行攔截，流程如圖3所示.

圖3 鑒權(quán)流程

3.4 權(quán)限信息生成算法

隨著系統(tǒng)業(yè)務(wù)規(guī)模的擴大，用戶權(quán)限信息也不斷增加，如果不采用一定的方式進行處理，Token的長度就會不斷增長，從而出現(xiàn)過多的網(wǎng)絡(luò)帶寬占用和超出服務(wù)器最大請求長度等問題.

對于Web應(yīng)用來說，權(quán)限信息實質(zhì)上是用戶所能訪問資源的統(tǒng)一資源定位符(Uniform Resource Locator，URL)，由于URL滿足層級結(jié)構(gòu)，因此可以將它設(shè)計成樹形結(jié)構(gòu).例如“/unit/addUnit”分為“unit”和“addUnit”，其中“unit”結(jié)點為“addUnit”的父結(jié)點.

URL之間往往存在包含關(guān)系，如“/user/student/query”包含“user/student”，在樹形結(jié)構(gòu)下，可以通過這樣的包含關(guān)系去除重復(fù)的結(jié)點，減少權(quán)限信息長度.但是因為這樣的關(guān)系，在遍歷URL樹時，難以判斷遍歷的結(jié)點是否為URL最終結(jié)點，所以必須給樹的每個結(jié)點添加是否為最終結(jié)點的標(biāo)志(圖4).

圖4 權(quán)限樹

權(quán)限信息生成算法具體流程如下：

(ⅰ)按照“/”分隔，將URL分級處理成一棵多叉權(quán)限樹，“/”為樹的根節(jié)點.

(ⅱ)將URL權(quán)限樹序列化成帶固定格式的權(quán)限字符串集合，第2級添加大括號，第3級添加中括號，第4級添加小括號，同級的URL結(jié)點用符號“|”分開.每個URL后添加0或1，代表是否為最后一個結(jié)點，如{user=0}[register=1|verificationCode=1|applyRetrieveCode=1|retrievePassword=1|]{unit=0}[**=1].

(ⅲ)通過GZIP壓縮算法進行權(quán)限字符串壓縮.

3.5 Token刷新機制

認(rèn)證成功后，在生成Access Token的基礎(chǔ)上也生成Refresh Token，并返回給客戶端.其中Refresh Token包含刷新Token時需要的用戶賬號信息和Redis中權(quán)限集合對應(yīng)的Key.

基于Refresh Token的靜默刷新機制如圖5所示.

圖5 刷新Token流程

刷新Token具體步驟如下：

(ⅰ)客戶端攜帶Token向服務(wù)器請求資源.

(ⅲ)在超文本傳輸協(xié)議(Hyper Text Transfer Protocol，HTTP)響應(yīng)頭中添加Token狀態(tài)刷新標(biāo)志(refresh_status)，同時服務(wù)器繼續(xù)處理請求，返回數(shù)據(jù)給客戶端.

(ⅳ)客戶端檢測到refresh_status刷新標(biāo)志，攜帶Refresh Token訪問認(rèn)證服務(wù)器的Token刷新接口.

(ⅳ)認(rèn)證服務(wù)器通過Refresh Token中的UUID去Redis數(shù)據(jù)庫中查找對應(yīng)用戶的權(quán)限集合，最后生成新的Token返回給客戶端.

4 測試結(jié)果

為了測試新型分布式權(quán)限控制系統(tǒng)與傳統(tǒng)權(quán)限系統(tǒng)的性能差異，在Centos7.9，Tomcat9.0，CPU 2.2 GHz，8.0 GB內(nèi)存的環(huán)境下分別部署這2種權(quán)限系統(tǒng)，進行實驗對比.

通過編寫多線程程序模擬用戶訪問服務(wù)器(其中一個線程代表一個用戶)，并在每個線程中基于HTTP協(xié)議不斷發(fā)送請求來模擬用戶操作，每次請求計算從發(fā)送請求到獲取響應(yīng)的時間間隔，最終統(tǒng)計出平均響應(yīng)時間.程序支持開啟給定數(shù)量的線程，本次測試模擬從100遞增到1 000的并發(fā)情況.表1示出了2個權(quán)限系統(tǒng)在不同用戶數(shù)量情況下平均響應(yīng)時間的變化情況.

表1 系統(tǒng)平均響應(yīng)時間對比

由表1可知，分布式權(quán)限控制系統(tǒng)的平均響應(yīng)時間始終比傳統(tǒng)權(quán)限系統(tǒng)的短，說明新型權(quán)限控制系統(tǒng)在分布式環(huán)境下顯著提升了系統(tǒng)性能.

5 結(jié)語

對當(dāng)前分布式環(huán)境下權(quán)限系統(tǒng)存在的問題進行了分析，并在分布式集群環(huán)境下，從認(rèn)證信息存儲、分布式鑒權(quán)和Token刷新機制等方面設(shè)計了可行性解決方案.系統(tǒng)采用“集中認(rèn)證，分散鑒權(quán)”模式與傳統(tǒng)認(rèn)證模式相比，能更好地適應(yīng)分布式集群環(huán)境，從而提升系統(tǒng)的整體性能和效率.