如何使用@Secured注解限制方法調用

本篇內容介紹了“如何使用@Secured注解限制方法調用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

保護方法應用

在Spring Securoty實現方法級別的安全性最常見的方法是使用特定的注解.將這些注解應用到需要保護的方法上.

Spring Security 提供了三種不同方式的安全注解.

• Spring 自帶的 @Security 注解.

• JSR-250 的 @RolesAllow 注解.

• 表達式驅動的注解: @PreAythorize , @PostAuthorize ,@PreFilter , @PostFilter .

@Secured和@RolesAllowed方案非常類似，能夠基于用戶所授予的權限限制對方法的訪問。
當我們需要在方法上定義更靈活的安全規則時，Spring Security提供了@PreAuthorize和@PostAuthorize，
而@PreFilter/@PostFilter能夠過濾方法返回的以及傳入方法的集合。

下面就開始介紹以上注解具體的使用方法.

使用@Secured注解限制方法調用

為了降低初學者的學識成本,我們使用最簡單的使用內存的用戶存儲來演示.

/**
 * @author itguang
 * @create
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter{

    //基于內存的用戶存儲
    @Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("itguang").password("123456").roles("USER").and()
                .withUser("admin").password("123456").roles("ADMIN");
    }

}

在Spring中如果要啟用基于注解的方法安全性,需要在配置類上使用@EnableGlobalMethodSecurity,如下所示:

/**
 * @author itguang
 * @create
@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration

除了@EnableGlobalMethodSecuroty注解外,我們注意到配置類還擴展了 GlobalMethodSecurotyConfiguration .
在前面的文章中我們介紹過 web安全的配置類擴展了 WebSecurityConfiguration ,與此類似,這個類能勾為方法級別的安全性提供精細的配置.

我們還可以看到 @EnableGlobalMethodSecuroty注解 的參數 securedEnabled 設置為了了true,這樣的話Spring Security就會包裝帶有
@Secured 注解的方法,例如:

@RequestMapping("/admin")
    @Secured("ROLE_ADMIN")
    public String admin(){
        return "admin";
    }

由于方法上添加了 @Secured(“ROLE_ADMIN”) 注解,當我們瀏覽器訪問 /admin 這個路徑時,Spring就會執行 admin()方法,Spring Security的切面
就會判斷當前用戶是否有 ROLE_ADMIN 的權限.

看到這里你可能會有疑惑,為什么是 ROLE_ADMIN 呢,我們的SecurityConfigure 配置類中命名設置的是 ADMIN 啊.
.withUser("admin").password("123456").roles("ADMIN"); ,其實這是Spring Security 自動為我們添加了 ROLE_ 前綴,
如果我們要寫成 .withUser("admin").password("123456").roles("ADMIN"); 的話,Spring Security就會報錯,

java.lang.IllegalArgumentException: ROLE_ADMIN cannot start with ROLE_ (it is automatically added)

可以看到Spring Security 提醒我們這是自動添加的前綴,因此我們么有必要再添加 ROLE_ 前綴.

但是,如果我們要為基于方法的攔截添加 @Secured 注解時,就必須添加 ROLE_ 的前綴.比如: @Secured("ROLE_ADMIN") .

測試

這里只給出主要的代碼,詳細代碼請參考源碼,本文最后會給出.

按照上面的配置完畢,我們啟動項目,訪問 http://localhost/admin ,會提示讓我們登陸,我們首先輸入一個沒有 ROLE_ADMIN 權限的用戶,
用戶名:itguang,密碼:123456. 點擊登陸,會發現瀏覽器返回下面的頁面:

http狀態碼為 403,很明顯就是無權限訪問.接下來我們在用 admin 用戶登陸,機會發現瀏覽器正確返回了 admin 字符串.

另外,@Secured會使用一個String數組作為參數,每個String值就是一個權限,調用這個方法的用戶至少要具備其中一個權限.如下面示例:

@RequestMapping("/hello")
    @Secured({"ROLE_ADMIN","ROLE_USER"})
    public String hello() {

        return "hello Spring Security";

    }

itguang 和 admin 這兩個用戶都可以訪問.如果方法被沒有被認證的用戶或者沒有相應權限的用戶訪問,就會拋出一個Spring Security 異常.
（可能是AuthenticationException或AccessDeniedException的子類）,他們是非檢查時異常,這個一場病最終必須被捕獲或者處理.
如果被保護的方法是在web中被調用的,這個異常會被Spring Security 的過濾器自動處理.否則的話,你需要編寫代碼來處理這個異常.

在Spring Security中使用JSR-250的@RolesAllowed注解

@RolesAllowed注解和@Secured注解在各個方面基本上都是一致的。唯一顯著的區別在于@RolesAllowed是JSR-250定義的Java標準注解.

如果選擇使用@RolesAllowed的話，需要將@EnableGlobalMethodSecurity的jsr250Enabled屬性設置為true，以開啟此功能.

/**
 * @author itguang
 * @create
@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true,jsr250Enabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration
    //基于內存的用戶存儲
    @Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("itguang").password("123456").roles("USER").and()
                .withUser("admin").password("123456").roles("ADMIN");
    }
}

盡管我們這里只是啟用了jsr250Enabled，但需要說明的一點是這與securedEnabled并不沖突。這兩種注解風格可以同時啟用.

如下:

@RequestMapping("/test1")
    @RolesAllowed("ROLE_ADMIN")
    public String test1(){
        return "test1";
    }

這兩個注解都有一個不足之處,它們只能根據用戶有沒有授予特定的權限來限制方法的調用,在判斷方式是否執行方面,無法使用其他的因素.
接下來，我們看一下如何組合使用SpEL與Spring Security所提供的方法調用前后注解，實現基于表達式的方法安全性.

使用表達式實現方法級別的安全性

Spring Security 3.0引入了幾個新注解，它們使用SpEL能夠在方法調用上實現更有意思的安全性約束。

• @PreAuthorize :在方法調用之前，基于表達式的計算結果來限制對方法的訪問

• @PostAuthorize 允許方法調用，但是如果表達式計算結果為false，將拋出一個安全性異常

• @PostFilter 允許方法調用，但必須按照表達式來過濾方法的結果

• @PreFilter 允許方法調用，但必須在進入方法之前過濾輸入值

這些注解的參數都可接受一個SPEL 表達式.表達式可以是任意合法的SPEL表達式.

如果表達式的計算結果為true，那么安全規則通過，否則就會失敗。安全規則通過或失敗的結果會因為所使用注解的差異而有所不同。

我們需要將@EnableGlobalMethod-Security注解的 prePostEnabled 屬性設置為true，從而啟用它們：

/**
 * @author itguang
 * @create
@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true,jsr250Enabled = true,prePostEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration
    //基于內存的用戶存儲
    @Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("itguang").password("123456").roles("USER").and()
                .withUser("admin").password("123456").roles("ADMIN");
    }


}

現在方法調用前后的注解都已經啟用了.

@PreAuthorize和@PostAuthorize

@PreAuthorize和@PostAuthorize，它們能夠基于表達式的計算結果來限制方法的訪問。
在定義安全限制方面，表達式帶了極大的靈活性。通過使用表達式，只要我們能夠想象得到，就可以定義任意允許訪問或不允許訪問方法的條件。

@PreAuthorize和@PostAuthorize之間的關鍵區別在于表達式執行的時機。
@PreAuthorize的表達式會在方法調用之前執行，如果表達式的計算結果不為true的話，將會阻止方法執行。
與之相反，@PostAuthorize的表達式直到方法返回才會執行，然后決定是否拋出安全性的異常。

在方法調用之前驗證權限,看下面的例子:

/**
 * @author itguang
 * @create
@RestController
public class UserController

    @RequestMapping("/addUser")
    @PreAuthorize("hasRole('ROLE_USER') and #userEntity.password>8 or hasRole('ROLE_ADMIN')")
    public String addUser(UserEntity userEntity){
        return "addUser ok";
    }

}

這段代碼是什么意思呢? 首先我們讓訪問 /addUser 的用戶 必須是擁有 ROLE_USER 的用戶,并且密碼長度大于8,或者擁有 ROLE_ADMIN 權限的.
這如果如使用@Secured或者RoleAllowd 是實現不了的.而使用 @PreAuthorized 恰好能適用這些場景.
表達式中 #userEntity 直接使用了方法中的同名參數,這使得Spring Security 能夠檢查傳入方法的參數.并將這些參數用于認證決策的指定.

在方法調用之后驗證權限,看下面的例子:

@RequestMapping("/getUser/{username}")
    @PostAuthorize("returnObject.username == principal.username")
    public UserEntity getUser(@PathVariable(value = "username") String username) {

        //模擬從數據庫中查找
        UserEntity userEntity = new UserEntity(username);

        return

啟動項目,我們首先訪問:http://localhost/getUser/itguang,會讓我們登陸,我們用itguang 用戶登陸,發現能夠正確返回,
然后我們在此基礎上再訪問 http://localhost/getUser/admin ,就會返回http狀態碼403,禁止訪問.說明配置生效.

下面我們來解釋一下上面的代碼,為了方便的訪問受保護方法的返回對象,Spring Security 在SPEL中提供了名為 returnObject的返回變量.
在這里我們知道返回對象是一個UserEntity,所以可以直接 returnObject.username 取得里面的參數.
principal 是另一個Spring Security 內置的特殊變量,它代表了當前認證用戶的主要信息,通常是用戶名和權限列表.

@PreAuthorize和@PostAuthorize—過濾方法的輸入和輸出

如果我們希望使用表達式來保護方法的話，那使用@PreAuthorize和@PostAuthorize是非常好的方案。但是，有時候限制方法調用太嚴格了。
有時，需要保護的并不是對方法的調用，需要保護的是傳入方法的數據和方法返回的數據.

事后對方法的返回值進行過濾,如下:

@RequestMapping("getAll")
    @PreAuthorize("hasRole('ROLE_USER')")
    @PostFilter("filterObject.enabled == true")
    public List<UserEntity> getAllUser(){

        ArrayList<UserEntity> list = new ArrayList<>();
        list.add(new UserEntity("test1","123456",true));
        list.add(new UserEntity("test1","123456",false));

        return

我們使用了 @PreAuthorize("hasRole('ROLE_USER')") @PostFilter("filterObject.enabled == true") 這兩個注解,
表明我們希望,用戶必須擁有 ROLE_USER 權限,并且返回用戶屬性 enabled為true的所有用戶.

表達式中的 filterObject 引用的是方法返回值List中的某一個元素,在這里是 UserEntity,并且過濾出 enabled為true的UserEntity,所以,
我們瀏覽器訪問 http://localhost/getAll,并用itguang用戶登錄后,返回的只有一條用戶的信息.

如果你覺得自己的安全表達式難以控制了，那么就應該看一下如何編
寫自定義的許可計算器（permission eval（232, 232, 232); background: rgb(249, 249, 249);">

@RequestMapping("/delete")
    @PreAuthorize("ROLE_USER")
    @PreFilter("hasPermission(targetObject,'delete')")
    public String getAllUser(List<UserEntity> list){
            //從數據庫中刪除數據
            //...

        return "ok";
    }

上面代碼實際上是在問一個問題,”當前用戶有權限刪除目標對象嗎?” 如果有的話,表達式計算為true,該對象會被刪除,

但是，hasPermission()是哪來的呢？它的意思是什么？更為重要
的是，它如何知道用戶有沒有權限刪除targetObject所對應的
User？

hasPermission()函數是Spring Security為SpEL提供的擴展，它為開發者提供了一個時機，能夠在執行計算的時候插入任意的邏輯。
我們所需要做的就是編寫并注冊一個自定義的許可計算器.

“如何使用@Secured注解限制方法調用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！