Spring Security 實戰乾貨：動態權限控制（上）思路

1. 前言

歡迎閱讀 Spring Security 實戰乾貨系列文章 。截止目前已經對 基於配置 和 基於註解 的角色訪問控制進行了講解。對於一些小項目來講基本是夠用的。然而若是但願運營管理人員可以動態的配置和分配權限，以上兩種方式顯然是知足不了需求的。接下來咱們來一塊兒探討一下思路。

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. 總結

本篇主要理清一下動態權限所須要的一些要點，並對請求認證的過程進行了分析。最後對結合安全框架定製也提供了一些我的的看法。實現也寫了大部分，之因此拆分紅上下篇，由於理論和實現放在一篇的話實在有點篇幅過長，分紅上篇理論、下篇實踐更加合適。