Spring Security 控制授權的方法

使用授權方法進行授權配置

每乙個 spring security 控制授權表示式（以下簡稱為表示式）實際上都在在 api 中對應乙個授權方法，該方法是請求的 url 許可權配置時的處理方法。例如：

使用授權表示式給多許可權要求的請求授權

那麼，何時需要用到表示式進行授權處理呢？乙個安全應用的許可權要求往往是複雜多樣的，比如，專案的除錯請求希望訪問者既要擁有管理員許可權又必須是通過公司內部區域網內部訪問。而這樣的需求下，僅僅通過security api 提供的方法是無法滿足的，因為這些授權方法是無法連續呼叫的。

此時就可以使用授權表示式解決：

授權表示式舉例說明

表示式說明

permitall

永遠返回 true

denyall

永遠返回 false

anonyous

當前使用者若是匿名使用者返回 true

rememberme

當前使用者若是 rememberme 使用者返回 true

authenticated

當前使用者若不是匿名（已認證）使用者返回 true

fullauthenticated

當前使用者若既不是匿名使用者又不是 rememberme 使用者時返回 true

hasrole(role)

當前使用者許可權集合中若擁有指定的 role 角色許可權（匹配時會在你所指定的許可權前加'role_'，即判斷是否有「role_role」許可權）時返回 true

hasanyrole(role1, role2, ...)

當前使用者許可權集合中若擁有任意乙個角色許可權時返回 true

hasauthority(authority)

當前使用者許可權集合中若具有 authority 許可權（匹配是否有「authority」許可權）時返回 true

hasanyauthority(authority)

程式設計客棧當前使用者許可權集合中若擁有任意乙個許可權時返回 true

hasipaddress("192.168.1.0/24")

傳送請求的ip匹配時fanhui true

基於角色的訪問控制 rbac（role-based access control）

或許你會認為上述方式已能滿足絕大rjipmkar多數應用安全授權管理。但事實上的企業級應用的授權往往是基於資料庫資料動態變化的，若是使用上述方式進行字串拼接，不僅對於開發者極不友好（每一次人人員變動都意味著需要改**，顯然不合理），而且應用的效能也會隨之降低。那麼，如何解決呢？

資料模型

通用的 rbac 資料模型，一般需要五張表（三張實體表，兩張關係表）rjipmkar。三張實體表包括使用者表、角色表、資源表。兩張關係表包括。其之間關係如下圖：

rbac資料模型

使用者表任何乙個使用者都必須要有使用者表，當公司發生人員變動時，由業務人員（如人力資源）對該資料表進行增刪記錄。

角色表公司有哪些身份的人，例如總裁、副程式設計客棧總裁、部門經理等，有業務人員根據公司的具體情況對該錶資料進行操作。

資源表儲存需要進行許可權控制的資源，由於我們進行控制授權時實際上是基於 url 的，但業務人員非按 url 組織資料條目，而是以檢視介面的形式進行曹操作。所以在這張表中儲存的是呈現給業務人員的選單、按鈕及其所進行許可權控制的 url 。

使用者—角色關係表

使用者表與角色表（使用者 id 與角色id ）之間是乙個多對多的關係。乙個使用者可以是多個角色（乙個使用者既可以是部門經理又可以是某個管理員），而乙個角色往往對應多個使用者。

角色—資源關係表

角色表與資源表（）也是乙個多對多的關係。一種角色可以訪問多個資源（按鈕或選單等），乙個資源也可以被多個角色訪問。

spring security 還支援自定義表示式來完成這項工作，就像這樣

本文標題: spring security 控制授權的方法

本文位址:

Spring Security 控制授權的方法

SpringSecurity頁面端許可權控制使用

星空控控控上ke控新浪部落格

spring security 安全框架

Spring Security 控制授權的方法

SpringSecurity頁面端許可權控制使用

星空 控控控 上ke控 新浪部落格

spring security 安全框架

相關推薦

星空控控控上ke控新浪部落格