大家好，我是不才陳某~

這是《Spring Cloud 進(jìn)階》第18篇文章，往期文章如下：

• 五十五張圖告訴你微服務(wù)的靈魂擺渡者Nacos究竟有多強(qiáng)？
• openFeign奪命連環(huán)9問，這誰受得了？
• 阿里面試這樣問：Nacos、Apollo、Config配置中心如何選型？這10個維度告訴你！
• 阿里面試敗北：5種微服務(wù)注冊中心如何選型？這幾個維度告訴你！
• 阿里限流神器Sentinel奪命連環(huán) 17 問？
• 對比7種分布式事務(wù)方案，還是偏愛阿里開源的Seata，真香！(原理+實(shí)戰(zhàn))
• Spring Cloud Gateway奪命連環(huán)10問？
• Spring Cloud Gateway 整合阿里 Sentinel網(wǎng)關(guān)限流實(shí)戰(zhàn)！
• 分布式鏈路追蹤之Spring Cloud Sleuth奪命連環(huán)9問？
• 鏈路追蹤自從用了SkyWalking，睡的真香！
• 3本書了，7萬+字，10篇文章，《Spring Cloud 進(jìn)階》基礎(chǔ)版 PDF
• 妹子始終沒搞懂OAuth2.0，今天整合Spring Cloud Security 一次說明白！
• OAuth2.0實(shí)戰(zhàn)！使用JWT令牌認(rèn)證！
• OAuth2.0實(shí)戰(zhàn)！玩轉(zhuǎn)認(rèn)證、資源服務(wù)異常自定義這些騷操作！
• 實(shí)戰(zhàn)干貨！Spring Cloud Gateway 整合 OAuth2.0 實(shí)現(xiàn)分布式統(tǒng)一認(rèn)證授權(quán)！
• 字節(jié)面試這樣問：跨庫多表存在大量數(shù)據(jù)依賴問題有哪些解決方案？
• 實(shí)戰(zhàn)！退出登錄時如何借助外力使JWT令牌失效？

這篇文章介紹下網(wǎng)關(guān)層如何集成RBAC權(quán)限模型進(jìn)行認(rèn)證鑒權(quán)，文章目錄如下：

什么是RBAC權(quán)限模型？

RBAC(Role-Based Access Control)基于角色訪問控制，目前使用最為廣泛的權(quán)限模型。

相信大家對這種權(quán)限模型已經(jīng)比較了解了。此模型有三個用戶、角色和權(quán)限，在傳統(tǒng)的權(quán)限模型用戶直接關(guān)聯(lián)加了角色層，解耦了用戶和權(quán)限，使得權(quán)限系統(tǒng)有了更清晰的職責(zé)劃分和更高的靈活度。

以上五張表的SQL就不再詳細(xì)貼出來了，都會放在案例源碼的doc目錄下，如下圖：

設(shè)計思路

RBAC權(quán)限模型是基于角色的，因此在Spring Security中的權(quán)限就是角色，具體的認(rèn)證授權(quán)流程如下：

1. 用戶登錄申請令牌
2. 通過UserDetailService查詢、加載用戶信息、比如密碼、權(quán)限(角色)....封裝到UserDetails中
3. 令牌申請成功，攜帶令牌訪問資源
4. 網(wǎng)關(guān)層面比較訪問的URL所需要的權(quán)限（Redis中）是否與當(dāng)前令牌具備的權(quán)限有交集。有交集則表示具備訪問該URL的權(quán)限。
5. 具備權(quán)限則訪問，否則拒絕

上述只是大致的流程，其中還有一些細(xì)節(jié)有待商榷，如下：

1、URL對應(yīng)的權(quán)限如何維護(hù)？

這個就比較容易實(shí)現(xiàn)了，涉及到RBAC權(quán)限模式的三張表，分別為權(quán)限表、角色表、權(quán)限角色對應(yīng)關(guān)系表。具體實(shí)現(xiàn)流程如下：

1. 項(xiàng)目啟動時將權(quán)限（URL）和角色的對應(yīng)關(guān)系加載到Redis中。
2. 對于管理界面涉及到URL相應(yīng)關(guān)系的變動要實(shí)時的變更到Redis。

比如權(quán)限中有這么一條數(shù)據(jù)，如下：

其中的 /order/info 這個URL就是一個權(quán)限，管理員可以對其分配給指定的角色。

2、如何實(shí)現(xiàn)Restful風(fēng)格的權(quán)限控制？

restful風(fēng)格的接口URL是相同的，不同的只是請求方式，因此要想做到權(quán)限的精細(xì)控制還需要保留請求方式，比如POST，GET，PUT，DELETE....

可以在權(quán)限表中的url字段放置一個method標(biāo)識，比如POST，此時的完整URL為：POST:/order/info

“

當(dāng)然*:/order/info中的星號表示一切請求方式都滿足。

”

3、這樣能實(shí)現(xiàn)動態(tài)權(quán)限控制嗎？

權(quán)限的控制方式有很多種，比如Security自身的注解、方法攔截，其實(shí)擴(kuò)展Spring Security也是可以實(shí)現(xiàn)動態(tài)權(quán)限控制的，這個在后面的文章中會單獨(dú)介紹！

陳某此篇文章是將權(quán)限、角色對應(yīng)關(guān)系存入Redis中，因此想要實(shí)現(xiàn)動態(tài)權(quán)限控制只需要在Redis中維護(hù)這種關(guān)系即可。Redis中的數(shù)據(jù)如下：

案例實(shí)現(xiàn)

此篇文章還是基于以下三個模塊進(jìn)行改動，有不清楚的可以查看陳某往期文章。

涉及到的更改目錄如下圖：

1、從數(shù)據(jù)庫加載URL<->角色對應(yīng)關(guān)系到Redis

在項(xiàng)目啟動之初直接讀取數(shù)據(jù)庫中的權(quán)限加載到Redis中，當(dāng)然方法有很多種，自己根據(jù)情況選擇。代碼如下：

此處代碼在oauth2-cloud-auth-server模塊下。

2、實(shí)現(xiàn)UserDetailsService加載權(quán)限

UserDetailsService相信大家都已經(jīng)很熟悉了，主要作用就是根據(jù)用戶名從數(shù)據(jù)庫中加載用戶的詳細(xì)信息。

代碼如下：

①處的代碼是將通過JPA從數(shù)據(jù)庫中查詢用戶信息并且組裝角色，必須是以 ROLE_ 開頭。

②處的代碼是將獲取的角色封裝進(jìn)入authorities向下傳遞。

此處代碼在oauth2-cloud-auth-server模塊下。

“

案例源碼已經(jīng)上傳GitHub，關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：9529 獲?。?/p>”

3、鑒權(quán)管理器中校驗(yàn)權(quán)限

在上篇文章中實(shí)戰(zhàn)干貨！Spring Cloud Gateway 整合 OAuth2.0 實(shí)現(xiàn)分布式統(tǒng)一認(rèn)證授權(quán)！詳細(xì)介紹了鑒權(quán)管理器的作用，這里就不再細(xì)說了。代碼如下：

①處的代碼是將請求URL組裝成restful風(fēng)格的，比如POST:/order/info

②處的代碼是從Redis中取出URL和角色對應(yīng)關(guān)系遍歷，通過AntPathMatcher進(jìn)行比對，獲取當(dāng)前請求URL的所需的角色。

③處的代碼就是比較當(dāng)前URL所需的角色和當(dāng)前用戶的角色，分為兩步：

• 如果是超級管理員，則直接放行，不必比較權(quán)限
• 不是超級管理員就需要比較角色，有交集才能放行

此處的代碼在oauth2-cloud-gateway模塊中。

“

案例源碼已經(jīng)上傳GitHub，關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：9529 獲??！

”

4、總結(jié)

關(guān)鍵代碼就是上述三處，另外關(guān)于一些DAO層的相關(guān)代碼就不再貼出來了，自己下載源碼看看！

“

案例源碼已經(jīng)上傳GitHub，關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：9529 獲??！

”

附加的更改

這篇文章中順帶將客戶端信息也放在了數(shù)據(jù)庫中，前面的文章都是放在內(nèi)存中。

數(shù)據(jù)庫中新建一張表，SQL如下：

CREATE TABLE `oauth_client_details` (
  `client_id` varchar(48) NOT NULL COMMENT '客戶端id',
  `resource_ids` varchar(256) DEFAULT NULL COMMENT '資源的id，多個用逗號分隔',
  `client_secret` varchar(256) DEFAULT NULL COMMENT '客戶端的秘鑰',
  `scope` varchar(256) DEFAULT NULL COMMENT '客戶端的權(quán)限，多個用逗號分隔',
  `authorized_grant_types` varchar(256) DEFAULT NULL COMMENT '授權(quán)類型，五種，多個用逗號分隔',
  `web_server_redirect_uri` varchar(256) DEFAULT NULL COMMENT '授權(quán)碼模式的跳轉(zhuǎn)uri',
  `authorities` varchar(256) DEFAULT NULL COMMENT '權(quán)限，多個用逗號分隔',
  `access_token_validity` int(11) DEFAULT NULL COMMENT 'access_token的過期時間，單位毫秒，覆蓋掉硬編碼',
  `refresh_token_validity` int(11) DEFAULT NULL COMMENT 'refresh_token的過期時間，單位毫秒，覆蓋掉硬編碼',
  `additional_information` varchar(4096) DEFAULT NULL COMMENT '擴(kuò)展字段，JSON',
  `autoapprove` varchar(256) DEFAULT NULL COMMENT '默認(rèn)false，是否自動授權(quán)',
  PRIMARY KEY (`client_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

認(rèn)證服務(wù)中的OAuth2.0的配置文件中將客戶端的信息從數(shù)據(jù)庫中加載，該實(shí)現(xiàn)類為JdbcClientDetailsService，關(guān)鍵代碼如下：

 @Override
    public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
        //使用JdbcClientDetailsService，從數(shù)據(jù)庫中加載客戶端的信息
        clients.withClientDetails(new JdbcClientDetailsService(dataSource));
    }

總結(jié)

本篇文章介紹了網(wǎng)關(guān)集成RBAC權(quán)限模型進(jìn)行認(rèn)證鑒權(quán)，核心思想就是將權(quán)限信息加載Redis緩存中，在網(wǎng)關(guān)層面的鑒權(quán)管理器中進(jìn)行權(quán)限的校驗(yàn)，其中還整合了Restful風(fēng)格的URL。

如果這篇文章對你有所幫助，或者有所啟發(fā)的話，幫忙點(diǎn)贊、在看、轉(zhuǎn)發(fā)、收藏，你的支持就是我堅持下去的最大動力！