昨天沒有審核公眾號發出了未修正的稿子，只能撤回，在此表示歉意！
1. 前言
歡迎閱讀 Spring Security 實戰干貨系列[1]文章 。截止目前已經對 基於配置 和 基於注解 的角色訪問控制進行了講解。對於一些小項目來說基本是夠用的。然而如果希望運營管理人員能夠動態的配置和分配權限，以上兩種方式顯然是滿足不了需求的。接下來我們來一起探討一下思路。
2. 動態權限同樣依賴 RBAC
我們依然應該在 RBAC 及其變種的基礎上構建動態的權限控制系統。所有被訪問的目標，無論是 API、靜態資源都應該是關聯了角色的東西統稱為 資源（Resource）。我們需要建立起角色和資源之間的關系。
2.1 資源映射到角色
下面是一個資源到角色的映射關系圖：
模型大致如上所示，每一個資源對應一個可能無重復的角色集（Set 集合）；你可以注意到一個細節 Role 1 既指向 Resource 1 又指向 Resource 2 中，這是可以理解的，畢竟有可能對同一資源的訪問權可能分散到多個角色中去；當然也可以互斥這取決於你的業務。我們選擇資源映射到角色是因為當請求時，資源是唯一的而角色可能是多個，如果進行反轉的話解析的效率低一些。
3. 請求認證過程
這里有很多搞法，但是總體的思路是我們的請求肯定是帶下面兩個東西（起碼在走到進行訪問決策這一步是必須有的）：
URI 訪問資源必然要用 URI 來定位，我們同樣通過 URI 來和資源接口進行匹配；最好是 Ant match，因為
/user/1和/user/2有可能訪問的是同一個資源接口。如果你想避免這種情況，要么在開發規約中禁止這種風格，這樣的好處是配置人員可以不必熟悉 Ant 風格；要么必須讓配置人員掌握 Ant 風格。Principal ，Spring Security 中為
Authentication（認證主體），之前講過的一個比較繞的概念，Spring Security 中的用戶身份有兩種 一種是 認證用戶 另一種是 匿名用戶 ，它們都包含角色。拿到角色到角色集進行匹配。
然后我畫了一個下面的圖來更加清晰的展示一下流程：
4. 如何結合安全框架
雖然本文是 Spring Security 系列的，但是我們如果使用其它安全框架或者自己研發安全框架都可以依據上面的思路。如果需要用編程語言總結一下就是我們需要兩個接口來協同：
獲取資源角色關系這些元數據的接口 這是我們動態權限控制的基石，只有將角色和資源的映射關系接口化才能動態的進行權限控制。這里沒有唯一標准，根據你的業務來設計。
對 Request 進行解析並和提取的元數據進行匹配的接口 這是我們動態權限控制的最終邏輯實現。這里的規則同樣也沒有唯一標准
抓住了這兩點之后我們就非常了然了，無非實現一個具有這兩種功能的 Filter ，注入安全框架的過濾鏈中的合適位置中。要么你可以自己造個輪子，要么你使用現在有的輪子。那么有沒有現成的輪子呢？我一般建議如果你在造輪子前先看看你選型的安全框架有沒有現成的輪子可用。當現成有輪子可用並且能夠滿足你的需要時往往能夠事半功倍。如果沒有合適的就造一個！
5. 總結
本篇主要理清一下動態權限所需要的一些要點，並對請求認證的過程進行了分析。最后對結合安全框架定制也提供了一些個人的見解。實現也寫了大部分，之所以拆分成上下篇，因為理論和實現放在一篇的話實在有點篇幅過長，分成上篇理論、下篇實踐更加合適。
參考資料
[1]
Spring Security 實戰干貨系列: https://www.felord.cn/categories/spring-security/
