一種基于OAuth2.0的微服務(wù)電力系統(tǒng)授權(quán)方案

吉書強(qiáng)

摘要：為解決傳統(tǒng)單體系統(tǒng)信息孤島問題，電力系統(tǒng)逐步向微服務(wù)架構(gòu)轉(zhuǎn)型。針對(duì)基于微服務(wù)的電力系統(tǒng)中高安全性、高擴(kuò)展性、高可靠性和低侵入性的要求，設(shè)計(jì)了一種基于OAuth2.0的授權(quán)方案，方案引入雙重校驗(yàn)機(jī)制，同時(shí)對(duì)客戶端和用戶進(jìn)行授權(quán)鑒權(quán)，滿足電力系統(tǒng)應(yīng)用需求。文中對(duì)該授權(quán)方案進(jìn)行了詳細(xì)的分析和闡述。

關(guān)鍵詞：微服務(wù);電力系統(tǒng);OAuth2.0;授權(quán);鑒權(quán)

中圖分類號(hào)：TP393.09 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2019）06-0103-03

0 引言

目前電力系統(tǒng)大多仍采用單體應(yīng)用模式，隨著各種系統(tǒng)數(shù)量的增加及單體應(yīng)用規(guī)模的擴(kuò)展，單體應(yīng)用的問題也逐漸暴露，如：應(yīng)用復(fù)雜、維護(hù)升級(jí)和擴(kuò)展新功能困難、相同業(yè)務(wù)需求因業(yè)務(wù)管理?xiàng)l塊分割、管理邊界重疊交叉、功能重復(fù)建設(shè)、信息不能共享形成信息孤島。隨著智能電網(wǎng)和計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)和通訊技術(shù)的快速發(fā)展，全球能源互聯(lián)網(wǎng)建設(shè)工作的不斷推進(jìn)，電力企業(yè)業(yè)務(wù)應(yīng)用系統(tǒng)和平臺(tái)建設(shè)逐步向規(guī)模化、多功能化、高效率和高性能的方向發(fā)展。

微服務(wù)[1]是一些協(xié)同工作的小而自治的服務(wù)，具有高內(nèi)聚和高自治性。微服務(wù)根據(jù)業(yè)務(wù)的邊界確定服務(wù)的邊界。服務(wù)之間通過網(wǎng)絡(luò)調(diào)用通信，加強(qiáng)服務(wù)之間的隔離，避免緊耦合。微服務(wù)架構(gòu)在應(yīng)對(duì)電力信息系統(tǒng)高實(shí)時(shí)性、高可靠性、高伸縮性及高擴(kuò)展性的要求具有很大優(yōu)勢，能夠解決傳統(tǒng)電力系統(tǒng)信息孤島問題。

云安全聯(lián)盟（Cloud Security Alliance）發(fā)布的《云安全指南V3.0》[2]中指出云安全中的身份認(rèn)證問題時(shí)信息系統(tǒng)的焦點(diǎn)問題之一?；谖⒎?wù)架構(gòu)的電力系統(tǒng)具有服務(wù)實(shí)例數(shù)量多、類型復(fù)雜、業(yè)務(wù)邏輯復(fù)雜、數(shù)據(jù)量龐大、安全性要求高和接入客戶端多等特點(diǎn)。如何有效控制不同客戶端及不同用戶的權(quán)限是一種挑戰(zhàn)。服務(wù)接入授權(quán)系統(tǒng)后，不能降低服務(wù)吞吐量，不能阻塞業(yè)務(wù)調(diào)度，更不能改變業(yè)務(wù)邏輯，對(duì)于已有的服務(wù)，在不改動(dòng)服務(wù)架構(gòu)的前提下，如何快速接入權(quán)限系統(tǒng)也是需要解決的問題。因此，設(shè)計(jì)一種能夠?qū)I(yè)務(wù)服務(wù)脫離權(quán)限校驗(yàn)細(xì)節(jié)且獨(dú)立、高可用、高安全性及高擴(kuò)展性的授權(quán)方案是非常必要的。

本文通過對(duì)OAuth2.0協(xié)議的詳細(xì)研究，提出了一種基于OAuth2.0協(xié)議的授權(quán)方案，能夠?qū)尤氲目蛻舳撕陀脩魧?shí)現(xiàn)雙重校驗(yàn)，降低基于微服務(wù)的電力系統(tǒng)集成授權(quán)功能的復(fù)雜度。

1 OAuth2.0協(xié)議

1.1 OAuth2.0協(xié)議

OAuth2.0是一種開放的協(xié)議，為桌面程序或者Web應(yīng)用提供了一種簡單的，標(biāo)準(zhǔn)的方式去訪問受保護(hù)的資源。OAuth 認(rèn)證授權(quán)具有簡單、安全、開放的特點(diǎn)。OAuth 2.0 關(guān)注客戶端開發(fā)者的簡易性，同時(shí)為 Web 應(yīng)用，桌面應(yīng)用和App提供專門的認(rèn)證流程。OAuth2.0協(xié)議授權(quán)流程圖如圖1所示。

OAuth 2.0協(xié)議主要有4種執(zhí)行角色（資源擁有者用戶、授權(quán)服務(wù)器、客戶端、資源服務(wù)器）定義了四種授權(quán)模式：

1.1.1 授權(quán)碼模式（Authorization Code）

授權(quán)碼模式（Authorization Code）是功能最完整、流程最嚴(yán)密的授權(quán)模式。它的特點(diǎn)就是通過客戶端后臺(tái)服務(wù)器與授權(quán)服務(wù)器進(jìn)行互動(dòng)。授權(quán)碼模式下用戶登錄授權(quán)后，授權(quán)服務(wù)器頒發(fā)授權(quán)碼，客戶端利用授權(quán)碼換取令牌（Access Token）進(jìn)行訪問。

1.1.2 密碼模式（Resource Owner Password Credentials）

密碼模式中，用戶向客戶端提供自己的用戶名和密碼?？蛻舳耸褂眠@些信息，向權(quán)限系統(tǒng)申請(qǐng)授權(quán)。這種模式只適用于用戶對(duì)客戶端高度信任的情況下。

1.1.3 隱藏模式（Implicit）

隱藏模式跳過授權(quán)碼步驟直接向客戶端頒發(fā)令牌，這種方式適用于令牌會(huì)話期有效的場景。

1.1.4 客戶端憑證（Client Credentials）

只針對(duì)客戶端進(jìn)行驗(yàn)證，而不對(duì)用戶驗(yàn)證，多個(gè)用戶可能共享同一個(gè)令牌。

1.2 授權(quán)流程優(yōu)化

在微服務(wù)應(yīng)用場景下，已有不少開發(fā)者對(duì)協(xié)議進(jìn)行了優(yōu)化[3-5]，但是對(duì)客戶端權(quán)限控制幾乎沒有。由于接入客戶端數(shù)量多，且電力系統(tǒng)應(yīng)用的安全性要求高，僅僅對(duì)客戶端或用戶進(jìn)行授權(quán)及鑒權(quán)都不合適，應(yīng)該要同時(shí)對(duì)客戶端及用戶進(jìn)行鑒權(quán)，以提高系統(tǒng)的安全性。為了解決以上問題，本文基于OAuth2.0協(xié)議結(jié)合JWT等技術(shù)，提出一種授權(quán)方案以提高電力系統(tǒng)安全性。方案將授權(quán)系統(tǒng)服務(wù)化，同時(shí)對(duì)客戶端及用戶鑒權(quán)，并降低對(duì)業(yè)務(wù)服務(wù)的侵入性，增強(qiáng)系統(tǒng)擴(kuò)展性，進(jìn)而增強(qiáng)電力系統(tǒng)的安全性與開放性。

2 授權(quán)方案的設(shè)計(jì)

基于微服務(wù)的電力系統(tǒng)架構(gòu)圖如圖2所示，系統(tǒng)統(tǒng)一通過Api網(wǎng)關(guān)提供服務(wù)接口，請(qǐng)求到達(dá)Api網(wǎng)關(guān)后轉(zhuǎn)發(fā)到授權(quán)服務(wù)器，進(jìn)行統(tǒng)一的認(rèn)證、授權(quán)和鑒權(quán)。業(yè)務(wù)系統(tǒng)不進(jìn)行權(quán)限驗(yàn)證，專注于業(yè)務(wù)處理。

客戶端接入授權(quán)系統(tǒng)前，需要在管理系統(tǒng)中提出申請(qǐng)并注冊Redirect_Uri（重定向地址），管理員審核通過后為客戶端分配App_ ID和App_Key，同時(shí)為客戶端分配可調(diào)配資源（Resources），有效期等信息。申請(qǐng)通過后客戶端可以接入授權(quán)系統(tǒng)，授權(quán)方案處理流程如下：

（1）用戶首次通過第三方客戶端發(fā)起資源請(qǐng)求時(shí)，客戶端先利用管理員分配的App_ ID和App_Key向授權(quán)服務(wù)器請(qǐng)求授權(quán)，授權(quán)服務(wù)器通過App_ID和App_Key驗(yàn)證客戶端有效性，驗(yàn)證成功后頒發(fā)客戶端令牌Client_Token，Client_Token具有時(shí)效性，驗(yàn)證不成功駁回客戶端請(qǐng)求。

（2）客戶端獲取Client_Token后發(fā)起授權(quán)請(qǐng)求，申請(qǐng)用戶進(jìn)行授權(quán)，請(qǐng)求包括Client_ Token、Response_Type（授權(quán)類型）、State（授權(quán)服務(wù)器直接返回）、Scope（授權(quán)范圍）和Redirect_Uri，授權(quán)服務(wù)器驗(yàn)證Client_Token及Redirect_Uri通過后，將用戶導(dǎo)向認(rèn)證登錄頁面，用戶輸入用戶名密碼后進(jìn)行登錄并對(duì)客戶端授權(quán)，授權(quán)服務(wù)器將用戶導(dǎo)向客戶端的重定向地址Redirect URI，同時(shí)返回Authorization Code（授權(quán)碼），授權(quán)碼時(shí)效性很短并且只能使用一次。

（3）客戶端使用Client_Token、Authorization Code訪問授權(quán)服務(wù)器授權(quán)端點(diǎn)換取訪問令牌，授權(quán)服務(wù)器對(duì)Client_Token和Authorization Code校驗(yàn)通過后銷毀授權(quán)碼并頒發(fā)具有有效期（Expires）的AccessToken（訪問令牌）給客戶端。

（4）客戶端攜帶Client_Token和AccessToken訪問資源服務(wù)器申請(qǐng)資源，客戶端需要同時(shí)提供Client_Token和AccessToken。

方案在授權(quán)流程中引入對(duì)客戶端權(quán)限的授權(quán)，并對(duì)客戶端的可申請(qǐng)資源進(jìn)行限制，加強(qiáng)對(duì)客戶端的安全控制增強(qiáng)系統(tǒng)安全性，改進(jìn)后的授權(quán)請(qǐng)求順序圖如圖3所示。

Api網(wǎng)關(guān)作為系統(tǒng)統(tǒng)一出入口，當(dāng)請(qǐng)求到達(dá)時(shí)，Api網(wǎng)關(guān)首先驗(yàn)證當(dāng)前請(qǐng)求是否攜帶Client_Token，如果未攜帶Client_Token直接駁回請(qǐng)求，驗(yàn)證通過后，Api網(wǎng)關(guān)判斷客戶端請(qǐng)求資源是否是公開資源，如果是公開資源直接轉(zhuǎn)發(fā)給資源服務(wù)器處理。請(qǐng)求保護(hù)資源時(shí)，Api網(wǎng)關(guān)進(jìn)一步檢測當(dāng)前請(qǐng)求是否攜帶Access_Token，檢測通過后，Api網(wǎng)關(guān)將Client_Token、Access_Token和請(qǐng)求發(fā)送給授權(quán)服務(wù)器進(jìn)行鑒權(quán)處理。驗(yàn)證未通過直接駁回請(qǐng)求。

授權(quán)服務(wù)器接收到請(qǐng)求后，首先根據(jù)Client_Token解析客戶端信息獲取客戶端可調(diào)用資源，檢驗(yàn)當(dāng)前請(qǐng)求資源是否在客戶端可調(diào)配資源范圍內(nèi)，如果不在可調(diào)配資源范圍內(nèi)則檢驗(yàn)不通過駁回請(qǐng)求。檢驗(yàn)通過后授權(quán)服務(wù)器根據(jù)AccessToken獲取當(dāng)前用戶角色及權(quán)限信息，校驗(yàn)用戶權(quán)限與當(dāng)前請(qǐng)求資源的權(quán)限是否匹配，匹配則校驗(yàn)通過，權(quán)限校驗(yàn)通過后，Api網(wǎng)關(guān)將請(qǐng)求轉(zhuǎn)發(fā)給目標(biāo)資源服務(wù)進(jìn)行響應(yīng)，如果校驗(yàn)未通過，駁回當(dāng)前請(qǐng)求。權(quán)限校驗(yàn)流程如圖4所示。

3 結(jié)語

本文基于微服務(wù)電力系統(tǒng)應(yīng)用場景，針對(duì)電力系統(tǒng)高安全性要求，在OAuth2.0協(xié)議的基礎(chǔ)上提出一種基于OAuth2.0的授權(quán)方案，對(duì)授權(quán)及鑒權(quán)流程進(jìn)行改進(jìn)引入雙重權(quán)限校驗(yàn)機(jī)制，對(duì)客戶端及用戶同時(shí)進(jìn)行授權(quán)鑒權(quán)，并對(duì)授權(quán)鑒權(quán)流程進(jìn)行了詳細(xì)設(shè)計(jì)和介紹。方案可擴(kuò)展性強(qiáng)，可靠性高，對(duì)業(yè)務(wù)服務(wù)屏蔽授權(quán)、鑒權(quán)細(xì)節(jié)，侵入性小。

參考文獻(xiàn)

[1] 辛園園，鈕俊，謝志軍，張開樂，毛昕怡.微服務(wù)體系結(jié)構(gòu)實(shí)現(xiàn)框架綜述[J].計(jì)算機(jī)工程與應(yīng)用，2018，54（19）：10-17.

[2] Cloud Security Alliance.The Treacherous Twelve.[EB/OL].（2016-04-02）[2016-03-15].http：//www.doit.com.cn/p/240905.html.

[3] 魏成坤，劉向東，石兆軍.基于OAuth2.0的認(rèn)證授權(quán)技術(shù)研究[J].信息網(wǎng)絡(luò)安全，2016（9）：6-11.

[4] 吳德，應(yīng)毅，毛道鶴.基于OAuth2.0的認(rèn)證授權(quán)方案設(shè)計(jì)與優(yōu)化[J].軟件，2018，39（10）：10-13.

[5] 歐海文，付永亮，于芋，胡馨月.一種改進(jìn)的OAuth授權(quán)機(jī)制有效性分析[J].計(jì)算機(jī)應(yīng)用與軟件，2017，34（12）：196-201.

OAuth2.0 Based Authorization Scheme in Microservice Electric System

JI Shu-qiang

（Nanjing Huadun Electric Power Information Security Assessment Co.，Ltd， Nanjing Jiangsu? 211106）

Abstract：To solve the problem of isolated information in traditional single system， Electric System are transitioning to micro-service architecture. In order to satisfy the requirements of high security， high scalability， high reliability and low invasion in electric system based on micro-service， We proposed an authorization scheme based on OAuth2.0. In which a double verification mechanism is introduced to authorize and authenticate the client and user at the same time. In this paper we analyzed and described the authorization scheme in detail.

Key words：Micro Service; Electric System; OAuth2.0; Authorize; Authenticate