背景

從傳統(tǒng)的單體應(yīng)用轉(zhuǎn)型Spring Cloud的朋友都在問我，Spring Cloud下的微服務(wù)權(quán)限怎么管？怎么設(shè)計(jì)比較合理？從大層面講叫服務(wù)權(quán)限，往小處拆分，分別為三塊：用戶認(rèn)證、用戶權(quán)限、服務(wù)校驗(yàn)。

用戶認(rèn)證

傳統(tǒng)的單體應(yīng)用可能習(xí)慣了session的存在，而到了Spring cloud的微服務(wù)化后，session雖然可以采取分布式會(huì)話來解決，但終究不是上上策。開始有人推行Spring Cloud Security結(jié)合很好的OAuth2，后面為了優(yōu)化OAuth 2中Access Token的存儲(chǔ)問題，提高后端服務(wù)的可用性和擴(kuò)展性，有了更好Token驗(yàn)證方式JWT（JSON Web Token）。這里要強(qiáng)調(diào)一點(diǎn)的是，OAuth2和JWT這兩個(gè)根本沒有可比性，是兩個(gè)完全不同的東西。
OAuth2是一種授權(quán)框架，而JWT是一種認(rèn)證協(xié)議

OAuth2認(rèn)證框架

OAuth2中包含四個(gè)角色：

• 資源擁有者(Resource Owner)

• 資源服務(wù)器(Resource Server)

• 授權(quán)服務(wù)器(Authorization Server)

• 客戶端(Client)

OAuth2包含4種授權(quán)模式

• 授權(quán)碼（認(rèn)證碼）模式 （Authorization code)

• 簡(jiǎn)化（隱形）模式 (Impilict

• 用戶名密碼模式 (Resource Owner Password Credential)

• 客戶端模式 (Client Credential)

其中，OAuth2的運(yùn)行流程如下圖，摘自RFC 6749：

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

我們?cè)赟pring Cloud OAuth2中，所有訪問微服務(wù)資源的請(qǐng)求都在Http Header中攜帶Token，被訪問的服務(wù)接下來再去請(qǐng)求授權(quán)服務(wù)器驗(yàn)證Token的有效性，目前這種方式，我們需要兩次或者更多次的請(qǐng)求，所有的Token有效性校驗(yàn)都落在的授權(quán)服務(wù)器上，對(duì)于我們系統(tǒng)的水平擴(kuò)展成為一個(gè)非常大的瓶頸。

JWT認(rèn)證協(xié)議

授權(quán)服務(wù)器將用戶信息和授權(quán)范圍序列化后放入一個(gè)JSON字符串，然后使用Base64進(jìn)行編碼，最終在授權(quán)服務(wù)器用私鑰對(duì)這個(gè)字符串進(jìn)行簽名，得到一個(gè)JSON Web Token。

假設(shè)其他所有的資源服務(wù)器都將持有一個(gè)RSA公鑰，當(dāng)資源服務(wù)器接收到這個(gè)在Http Header中存有Token的請(qǐng)求，資源服務(wù)器就可以拿到這個(gè)Token，并驗(yàn)證它是否使用正確的私鑰簽名（是否經(jīng)過授權(quán)服務(wù)器簽名，也就是驗(yàn)簽）。驗(yàn)簽通過，反序列化后就拿到Toekn中包含的有效驗(yàn)證信息。

其中，主體運(yùn)作流程圖如下：

+-----------+                                     +-------------+
|           |       1-Request Authorization       |             |
|           |------------------------------------>|             |
|           |     grant_type&username&password    |             |--+
|           |                                     |Authorization|  | 2-Gen
|           |                                     |Service      |  |   JWT
|           |       3-Response Authorization      |             |<-+
|           |<------------------------------------| Private Key |
|           |    access_token / refresh_token     |             |
|           |    token_type / expire_in           |             |
|  Client   |                                     +-------------+
|           |                                 
|           |                                     +-------------+
|           |       4-Request Resource            |             |
|           |-----------------------------------> |             |
|           | Authorization: bearer Access Token  |             |--+
|           |                                     | Resource    |  | 5-Verify
|           |                                     | Service     |  |  Token
|           |       6-Response Resource           |             |<-+
|           |<----------------------------------- | Public Key  |
+-----------+                                     +-------------+

通過上述的方式，我們可以很好地完成服務(wù)化后的用戶認(rèn)證。

用戶權(quán)限

傳統(tǒng)的單體應(yīng)用的權(quán)限攔截，大家都喜歡shiro，而且用的頗為順手?？墒且坏┎鸱趾?，這權(quán)限開始分散在各個(gè)API了，shiro還好使嗎？筆者在項(xiàng)目中，并沒有用shiro。前后端分離后，交互都是token，后端的服務(wù)無狀態(tài)化，前端按鈕資源化，權(quán)限放哪兒管好使？

抽象與設(shè)計(jì)

在介紹靈活的核心設(shè)計(jì)前，先給大家普及一個(gè)入門的概念：RBAC（Role-Based Access Control，基于角色的訪問控制），就是用戶通過角色與權(quán)限進(jìn)行關(guān)聯(lián)。簡(jiǎn)單地說，一個(gè)用戶擁有若干角色，每一個(gè)角色擁有若干權(quán)限。

RBAC其實(shí)是一種分析模型，主要分為：基本模型RBAC0（Core RBAC）、角色分層模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統(tǒng)一模型RBAC3（Combines RBAC）。

更多詳情大家可以了解：RBAC權(quán)限模型

核心UML

這是筆者通過多種業(yè)務(wù)場(chǎng)景后抽象的RBAC關(guān)系圖

類說明

• Group

群或組，擁有一定數(shù)量權(quán)限的集合，亦可以是權(quán)限的載體。

子類：User（用戶）、Role（角色）、Position（崗位）、Unit（部門），通過用戶的特定構(gòu)成，形成不同業(yè)務(wù)場(chǎng)景的群或組，而通過對(duì)群或組的父類授權(quán)，完成了用戶的權(quán)限獲取。

• Permission

權(quán)限，擁有一定數(shù)量資源的集成，亦可以是資源的載體。

• Resources

權(quán)限下有資源，資源的來源有：Menu（菜單）、Button（動(dòng)作權(quán)限）、頁面元素（按鈕、tab等）、數(shù)據(jù)權(quán)限等

• Program

程序，相關(guān)權(quán)限控制的呈現(xiàn)載體，可以在多個(gè)菜單中掛載。

• 常見web程序基本構(gòu)成

模型與微服務(wù)的關(guān)系

如果把Spring Cloud服務(wù)化后的所有api接口都定義為上文的Resources，那么我們可以看到這么一個(gè)情況。

比如一個(gè)用戶的增刪改查，我們的頁面會(huì)這么做

在抽象成上述的映射關(guān)系后，我們的前后端的資源有了參照，我們對(duì)于用戶組的權(quán)限授權(quán)就容易了。比如我授予一個(gè)用戶增加、刪除權(quán)限。在前端我們只需要檢驗(yàn)該資源編碼的有無就可以控制按鈕的顯示和隱藏，而在后端我們只需要統(tǒng)一攔截判斷該用戶是否具有URI和對(duì)應(yīng)請(qǐng)求方式即可。

至于權(quán)限的統(tǒng)一攔截是放置在Zuul這個(gè)網(wǎng)關(guān)上，還是落在具體的后端服務(wù)的攔截器上（Filter、Inteceptor），都可以輕而易舉地實(shí)現(xiàn)。不在局限于代碼的侵入性。放置Zuul流程圖如下：

要是權(quán)限的統(tǒng)一攔截放置在Zuul上，會(huì)有一個(gè)問題，那就是后端服務(wù)安不安全，服務(wù)只需要通過注冊(cè)中心，即可對(duì)其他服務(wù)進(jìn)行調(diào)用。這里就涉及到后面的第三個(gè)模塊，服務(wù)之間的鑒權(quán)。

服務(wù)之間的鑒權(quán)

因?yàn)槲覀兌贾婪?wù)之間開源通過注冊(cè)中心尋到客戶端后，直接遠(yuǎn)程過程調(diào)用的。對(duì)于生產(chǎn)上的各個(gè)服務(wù)，一個(gè)個(gè)敏感性的接口，我們更是需要加以保護(hù)。主題的流程如下圖：

筆者的實(shí)現(xiàn)方式是基于Spring Cloud的FeignClient Inteceprot（自動(dòng)申請(qǐng)服務(wù)token、傳遞當(dāng)前上下文）和Mvc Inteceptor（服務(wù)token校驗(yàn)、更新當(dāng)前上下文）來實(shí)現(xiàn)，從而對(duì)服務(wù)的安全性做進(jìn)一步保護(hù)。

結(jié)合Spring Cloud的特性后，整體流程圖如下：

優(yōu)化點(diǎn)

雖然通過上述的用戶合法性檢驗(yàn)、用戶權(quán)限攔截以及服務(wù)之間的鑒權(quán)，保證了Api接口的安全性，但是其間的Http訪問頻率是比較高的，請(qǐng)求數(shù)量上來的時(shí)候，慢的問題是就會(huì)特別明顯。可以考慮一定的優(yōu)化策略，比如用戶權(quán)限緩存、服務(wù)授權(quán)信息的派發(fā)與混存、定時(shí)刷新服務(wù)鑒權(quán)Token等。