更新時間:2022-02-08 10:23:11 來源:動力節(jié)點 瀏覽1098次
授權,也叫訪問控制,即在應用中控制誰能訪問哪些資源(如訪問頁面/編輯數(shù)據(jù)/頁面操作等)。在授權中需了解的幾個關鍵對象:主體(Subject)、資源(Resource)、權限(Permission)、角色(Role)。
主體 主體,即訪問應用的用戶,在 Shiro 中使用 Subject 代表該用戶。用戶只有授權后才允許訪問相應的資源。
資源 在應用中用戶可以訪問的URL,比如訪問 JSP 頁面、查看/編輯某些數(shù)據(jù)、訪問某個業(yè)務方法、打印文本等等都是資源。用戶只要授權后才能訪問。
權限 安全策略中的原子授權單位,通過權限我們可以表示在應用中用戶有沒有操作某個資源的權力。即權限表示在應用中用戶能不能訪問某個資源,如: 訪問用戶列表頁面 查看/新增/修改/刪除用戶數(shù)據(jù)(即很多時候都是 CRUD(增查改刪)式權限控制)打印文檔等。如上可以看出,權限代表了用戶有沒有操作某個資源的權利,即反映在某個資源上的操作允不允許,不反映誰去執(zhí)行這個操作。所以后續(xù)還需要把權限賦予給用戶,即定義哪個用戶允許在某個資源上做什么操作(權限),Shiro 不會去做這件事情,而是由實現(xiàn)人員提供。
Shiro 支持粗粒度權限(如用戶模塊的所有權限)和細粒度權限(操作某個用戶的權限,即實例級別的),后續(xù)部分介紹。
角色 角色代表了操作集合,可以理解為權限的集合,一般情況下我們會賦予用戶角色而不是權限,即這樣用戶可以擁有一組權限,賦予權限時比較方便。典型的如:項目經(jīng)理、技術總監(jiān)、CTO、開發(fā)工程師等都是角色,不同的角色擁有一組不同的權限。
隱式角色: 即直接通過角色來驗證用戶有沒有操作權限,如在應用中 CTO、技術總監(jiān)、開發(fā)工程師可以使用打印機,假設某天不允許開發(fā)工程師使用打印機,此時需要從應用中刪除相應代碼;再如在應用中 CTO、技術總監(jiān)可以查看用戶、查看權限;突然有一天不允許技術總監(jiān)查看用戶、查看權限了,需要在相關代碼中把技術總監(jiān)角色從判斷邏輯中刪除掉;即粒度是以角色為單位進行訪問控制的,粒度較粗;如果進行修改可能造成多處代碼修改。
顯示角色: 在程序中通過權限控制誰能訪問某個資源,角色聚合一組權限集合;這樣假設哪個角色不能訪問某個資源,只需要從角色代表的權限集合中移除即可;無須修改多處代碼;即粒度是以資源/實例為單位的;粒度較細。
請 google 搜索“RBAC”和“RBAC新解”分別了解“基于角色的訪問控制”“基于資源的訪問控制(Resource-Based Access Control)”。
Shiro 支持三種方式的授權:
編程式:通過寫 if/else 授權代碼塊完成:
Subject subject = SecurityUtils.getSubject();
if(subject.hasRole(“admin”)) {
//有權限
} else {
//無權限
}
注解式:通過在執(zhí)行的 Java 方法上放置相應的注解完成:
@RequiresRoles("admin")
public void hello() {
//有權限
}
沒有權限將拋出相應的異常;
JSP/GSP 標簽:在 JSP/GSP 頁面通過相應的標簽完成:
<shiro:hasRole name="admin">
<!— 有權限 —>
</shiro:hasRole>
后續(xù)部分將詳細介紹如何使用。
基于角色的訪問控制(隱式角色)
1.在 ini 配置文件配置用戶擁有的角色(shiro-role.ini)
[users]
zhang=123,role1,role2
wang=123,role1
規(guī)則即:“用戶名=密碼,角色1,角色2”,如果需要在應用中判斷用戶是否有相應角色,就需要在相應的 Realm 中返回角色信息,也就是說 Shiro 不負責維護用戶-角色信息,需要應用提供,Shiro 只是提供相應的接口方便驗證,后續(xù)會介紹如何動態(tài)的獲取用戶角色。
2.測試用例(com.github.zhangkaitao.shiro.chapter3.RoleTest)
@Test
public void testHasRole() {
login("classpath:shiro-role.ini", "zhang", "123");
//判斷擁有角色:role1
Assert.assertTrue(subject().hasRole("role1"));
//判斷擁有角色:role1 and role2
Assert.assertTrue(subject().hasAllRoles(Arrays.asList("role1", "role2")));
//判斷擁有角色:role1 and role2 and !role3
boolean[] result = subject().hasRoles(Arrays.asList("role1", "role2", "role3"));
Assert.assertEquals(true, result[0]);
Assert.assertEquals(true, result[1]);
Assert.assertEquals(false, result[2]);
}
Shiro 提供了 hasRole/hasRoles 用于判斷用戶是否擁有某個角色/某些權限;但是沒有提供如 hashAnyRole 用于判斷是否有某些權限中的某一個。
@Test(expected = UnauthorizedException.class)
public void testCheckRole() {
login("classpath:shiro-role.ini", "zhang", "123");
//斷言擁有角色:role1
subject().checkRole("role1");
//斷言擁有角色:role1 and role3 失敗拋出異常
subject().checkRoles("role1", "role3");
}
Shiro 提供的 checkRole/checkRoles 和 hasRole/hasAllRoles 不同的地方是它在判斷為假的情況下會拋出 UnauthorizedException 異常。
到此基于角色的訪問控制(即隱式角色)就完成了,這種方式的缺點就是如果很多地方進行了角色判斷,但是有一天不需要了那么就需要修改相應代碼把所有相關的地方進行刪除;這就是粗粒度造成的問題。
基于資源的訪問控制(顯示角色)
1.在 ini 配置文件配置用戶擁有的角色及角色-權限關系(shiro-permission.ini)
[users]
zhang=123,role1,role2
wang=123,role1
[roles]
role1=user:create,user:update
role2=user:create,user:delete
規(guī)則:“用戶名=密碼,角色 1,角色 2”“角色=權限 1,權限 2”,即首先根據(jù)用戶名找到角色,然后根據(jù)角色再找到權限;即角色是權限集合;Shiro 同樣不進行權限的維護,需要我們通過 Realm 返回相應的權限信息。只需要維護“用戶——角色”之間的關系即可。
2.測試用例(com.github.zhangkaitao.shiro.chapter3.PermissionTest)
@Test
public void testIsPermitted() {
login("classpath:shiro-permission.ini", "zhang", "123");
//判斷擁有權限:user:create
Assert.assertTrue(subject().isPermitted("user:create"));
//判斷擁有權限:user:update and user:delete
Assert.assertTrue(subject().isPermittedAll("user:update", "user:delete"));
//判斷沒有權限:user:view
Assert.assertFalse(subject().isPermitted("user:view"));
}
Shiro 提供了 isPermitted 和 isPermittedAll 用于判斷用戶是否擁有某個權限或所有權限,也沒有提供如 isPermittedAny 用于判斷擁有某一個權限的接口。
@Test(expected = UnauthorizedException.class)
public void testCheckPermission () {
login("classpath:shiro-permission.ini", "zhang", "123");
//斷言擁有權限:user:create
subject().checkPermission("user:create");
//斷言擁有權限:user:delete and user:update
subject().checkPermissions("user:delete", "user:update");
//斷言擁有權限:user:view 失敗拋出異常
subject().checkPermissions("user:view");
}
但是失敗的情況下會拋出 UnauthorizedException 異常。
到此基于資源的訪問控制(顯示角色)就完成了,也可以叫基于權限的訪問控制,這種方式的一般規(guī)則是“資源標識符:操作”,即是資源級別的粒度;這種方式的好處就是如果要修改基本都是一個資源級別的修改,不會對其他模塊代碼產(chǎn)生影響,粒度小。但是實現(xiàn)起來可能稍微復雜點,需要維護“用戶——角色,角色——權限(資源:操作)”之間的關系。如果您想了解更多相關知識,不妨來關注一下動力節(jié)點的Shiro視頻教程,里面的課程內(nèi)容詳細,通俗易懂,適合沒有基礎的小白學習,希望對大家能夠有所幫助。