現(xiàn)授權(quán)：從原理到權(quán)限數(shù)據(jù)模型實(shí)踐)
Java Shiro 安全框架十自定義 Realm 實(shí)現(xiàn)授權(quán)做了幾個(gè) Shiro 項(xiàng)目之后我發(fā)現(xiàn)很多同學(xué)對(duì)“登錄成功”這件事特別上心但對(duì)“登錄之后能干什么”往往只有一個(gè)模糊概念反正登錄進(jìn)去了頁(yè)面上的按鈕該不該顯示、接口該不該讓調(diào)、數(shù)據(jù)該不該讓看這些才是一個(gè)安全框架真正值錢(qián)的地方。Shiro 的授權(quán)Authorization能力雖然接口簡(jiǎn)單但要把權(quán)限數(shù)據(jù)從數(shù)據(jù)庫(kù)里撈出來(lái)、裝進(jìn)框架能識(shí)別的結(jié)構(gòu)、再讓注解和標(biāo)簽正常工作中間的關(guān)鍵節(jié)點(diǎn)就是“自定義 Realm”。這篇文章我打算只講授權(quán)這一半。默認(rèn)你已經(jīng)跑通了認(rèn)證Authentication知道 Realm 是 Shiro 連接數(shù)據(jù)源的那座橋。我們順著這座橋繼續(xù)往前走把doGetAuthorizationInfo這個(gè)方法的里里外外都拆一遍從數(shù)據(jù)模型設(shè)計(jì)、代碼實(shí)現(xiàn)、調(diào)試驗(yàn)證到生產(chǎn)環(huán)境最容易踩的緩存和權(quán)限串號(hào)問(wèn)題一次說(shuō)清楚。1. 自定義 Realm 在 Shiro 授權(quán)中的定位1.1 授權(quán)和認(rèn)證是兩套獨(dú)立的動(dòng)作很多人第一次接觸 Shiro 時(shí)會(huì)以為“登錄數(shù)據(jù)都從數(shù)據(jù)庫(kù)查了順手把權(quán)限也查出來(lái)不就行了”。邏輯上沒(méi)問(wèn)題但 Shiro 的設(shè)計(jì)把這兩件事拆得很干凈認(rèn)證回答“你是誰(shuí)”授權(quán)回答“你能干什么”。這兩件事在代碼層面分別對(duì)應(yīng) Realm 里的兩個(gè)方法——doGetAuthenticationInfo和doGetAuthorizationInfo。之所以非要拆開(kāi)是因?yàn)槭跈?quán)判斷發(fā)生的時(shí)機(jī)遠(yuǎn)比登錄時(shí)多。用戶(hù)登錄時(shí)你當(dāng)然可以查出他所有角色權(quán)限并塞進(jìn) Session但真實(shí)系統(tǒng)里權(quán)限經(jīng)常變化管理員給用戶(hù)加了個(gè)角色、用戶(hù)被移出了某個(gè)部門(mén)、權(quán)限菜單被調(diào)整。如果只在登錄時(shí)查一次那這些變更只能等用戶(hù)重新登錄才生效太不靈活。Shiro 的做法是每次執(zhí)行subject.isPermitted()或subject.hasRole()時(shí)動(dòng)態(tài)向 Realm 要一次授權(quán)數(shù)據(jù)再配合緩存把性能問(wèn)題解決掉。所以自定義 Realm 的授權(quán)部分本質(zhì)上就是實(shí)現(xiàn)一個(gè)“按用戶(hù)查角色和權(quán)限”的查詢(xún)器。你的業(yè)務(wù)邏輯再?gòu)?fù)雜最終都得收斂到給它返回一個(gè)AuthorizationInfo。1.2 內(nèi)置 Realm 的授權(quán)能力為什么不夠用Shiro 自帶了好幾款開(kāi)箱即用的 Realm比如IniRealm、PropertiesRealm、JdbcRealm。其中JdbcRealm最容易被拿來(lái)直接對(duì)接數(shù)據(jù)庫(kù)它默認(rèn)的權(quán)限查詢(xún) SQL 是這樣的select role_name from user_roles where username ?以及select permission from roles_permissions where role_name ?這套表結(jié)構(gòu)設(shè)計(jì)的初衷是“一個(gè)用戶(hù)直接關(guān)聯(lián)角色角色直接關(guān)聯(lián)權(quán)限”簡(jiǎn)單直接。但真實(shí)業(yè)務(wù)表很少長(zhǎng)這樣常見(jiàn)情況是用戶(hù)表、角色表、用戶(hù)角色關(guān)聯(lián)表、權(quán)限表、角色權(quán)限關(guān)聯(lián)表五張表起步而且用戶(hù)名可能是郵箱、手機(jī)號(hào)或企業(yè)內(nèi)部工號(hào)。你要是為了湊JdbcRealm的默認(rèn) SQL 去改業(yè)務(wù)表結(jié)構(gòu)那純粹是本末倒置。更關(guān)鍵的是JdbcRealm默認(rèn)權(quán)限模型過(guò)于扁平它無(wú)法表達(dá)層級(jí)權(quán)限也沒(méi)法讓你在權(quán)限數(shù)據(jù)里塞入自定義的過(guò)濾條件。所以項(xiàng)目的通用做法是把AuthorizingRealm拿過(guò)來(lái)繼承自己寫(xiě)查詢(xún)邏輯。這就是“自定義 Realm 實(shí)現(xiàn)授權(quán)”這個(gè)主題存在的根本原因。1.3 一條權(quán)限判斷背后的完整調(diào)用鏈我習(xí)慣在講代碼前先讓讀者腦子里有一張調(diào)用圖。你寫(xiě)業(yè)務(wù)代碼時(shí)只調(diào)了一句if (subject.isPermitted(order:export)) { // 允許導(dǎo)出訂單 }這一句話(huà)背后發(fā)生了什么完整鏈路大致是這樣Subject委托給SecurityManager。SecurityManager繼續(xù)傳給Authorizer默認(rèn)實(shí)現(xiàn)是ModularRealmAuthorizer。ModularRealmAuthorizer遍歷當(dāng)前 SecurityManager 里注冊(cè)的所有 Realm逐個(gè)詢(xún)問(wèn)realm.isPermitted(principal, permission)。每個(gè) Realm 內(nèi)部會(huì)先檢查緩存沒(méi)有緩存就調(diào)用doGetAuthorizationInfo(principalCollection)加載授權(quán)數(shù)據(jù)。授權(quán)數(shù)據(jù)拿到后和當(dāng)前要判斷的Permission做匹配返回 boolean。有意思的是第三步ModularRealmAuthorizer會(huì)“遍歷所有 Realm 并一票制決定結(jié)果”。這是什么意思只要有一個(gè) Realm 說(shuō)“允許”整個(gè)判斷結(jié)果就是允許。這意味著如果你同時(shí)配置了多個(gè) Realm哪怕某個(gè) Realm 里壓根查不到這個(gè)用戶(hù)的權(quán)限只要另一個(gè) Realm 查到了授權(quán)請(qǐng)求依然能通過(guò)。這個(gè)小細(xì)節(jié)在生產(chǎn)環(huán)境里會(huì)帶來(lái)一些詭異現(xiàn)象后面我會(huì)專(zhuān)門(mén)講。2. 從 AuthorizingRealm 切入授權(quán)的骨架2.1 doGetAuthorizationInfo 是唯一的核心入口AuthorizingRealm這個(gè)抽象類(lèi)幫我們做了大量模板化工作。它繼承自AuthenticatingRealm在認(rèn)證能力基礎(chǔ)上擴(kuò)展了授權(quán)能力。我們要實(shí)現(xiàn)的方法只有一個(gè)protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals)參數(shù)PrincipalCollection里裝著用戶(hù)身份標(biāo)識(shí)。別小看這個(gè)參數(shù)它可能包含多個(gè) Realm 各自返回的 principal所以你在取用戶(hù)標(biāo)識(shí)時(shí)不能想當(dāng)然用principals.getPrimaryPrincipal()要看你認(rèn)證時(shí)SimpleAuthenticationInfo里到底放的是什么對(duì)象。返回的AuthorizationInfo就是授權(quán)數(shù)據(jù)的容器最常用的實(shí)現(xiàn)類(lèi)是SimpleAuthorizationInfo它內(nèi)部維護(hù)了三類(lèi)數(shù)據(jù)方法作用常見(jiàn)用法addRole(String)添加單個(gè)角色標(biāo)識(shí)info.addRole(admin)addRoles(SetString)批量添加角色從數(shù)據(jù)庫(kù)查詢(xún)結(jié)果直接放入addStringPermission(String)添加字符串權(quán)限info.addStringPermission(order:export)addObjectPermission(Permission)添加對(duì)象權(quán)限自定義 Permission 實(shí)現(xiàn)時(shí)使用很多初學(xué)者會(huì)糾結(jié)“角色和權(quán)限到底往哪個(gè)里面放”。我的建議是角色照常放權(quán)限也照常放兩者并不沖突。角色用于粗粒度的功能入口控制權(quán)限用于細(xì)粒度的操作控制后面會(huì)展開(kāi)講。2.2 授權(quán)數(shù)據(jù)該從哪里來(lái)doGetAuthorizationInfo方法體里面一般就三步拿用戶(hù)標(biāo)識(shí)、查數(shù)據(jù)庫(kù)、組裝AuthorizationInfo。真正的業(yè)務(wù)復(fù)雜點(diǎn)全在第二步。這里我要強(qiáng)調(diào)一個(gè)容易被忽視的設(shè)計(jì)問(wèn)題授權(quán)查詢(xún)到底應(yīng)該按用戶(hù)主鍵查還是按用戶(hù)名查如果認(rèn)證時(shí)你往 principal 里塞的是用戶(hù)主鍵userId那授權(quán)查詢(xún)就用userId做條件。如果塞的是用戶(hù)名就按用戶(hù)名查。兩種都可以但我更推薦主鍵因?yàn)橛脩?hù)名可能被修改而且即使兩個(gè)用戶(hù)同一天注冊(cè)、同名主鍵也不會(huì)撞。唯一的注意點(diǎn)是Subject的 API 大多接收 principal 作為參數(shù)你從principals.getPrimaryPrincipal()取出來(lái)的類(lèi)型必須和你放進(jìn)去時(shí)一致否則要做類(lèi)型判斷再轉(zhuǎn)換。至于查詢(xún)結(jié)果我也順手說(shuō)一個(gè)實(shí)踐不要在doGetAuthorizationInfo里一次只查角色另一次只查權(quán)限最好一條查詢(xún)把用戶(hù)的角色碼列表查出來(lái)再用角色集合去查權(quán)限集合。這樣可以減少數(shù)據(jù)庫(kù)交互次數(shù)。很多同學(xué)在緩存沒(méi)生效的開(kāi)發(fā)階段會(huì)反復(fù)看到 SQL 日志里授權(quán)查詢(xún)刷屏通常就是這里多查了幾趟。2.3 授權(quán)緩存Shiro 替你省了多少事AuthorizingRealm內(nèi)置了授權(quán)緩存。默認(rèn)情況下緩存是關(guān)閉的你需要設(shè)置authorizationCachingEnabled true并提供一個(gè)CacheManager。如果什么都不配每一次isPermitted()判斷都會(huì)真實(shí)觸發(fā)doGetAuthorizationInfo查詢(xún)數(shù)據(jù)庫(kù)性能上是災(zāi)難。這里的坑在于緩存默認(rèn) key 是AuthorizationCacheKey基于 principal 計(jì)算。什么意思呢用戶(hù) A 的權(quán)限被緩存后如果管理員修改了 A 的權(quán)限再判斷A.isPermitted(...)時(shí) Shiro 不會(huì)主動(dòng)知道你數(shù)據(jù)庫(kù)變了它只會(huì)從緩存里取出舊數(shù)據(jù)。這就是“權(quán)限變更后不生效”的經(jīng)典問(wèn)題。解決思路有兩個(gè)一是使用像 Redis 這樣的分布式緩存并主動(dòng)清理 key二是實(shí)現(xiàn)一個(gè)帶版本號(hào)的緩存策略。最省事的辦法是在權(quán)限變更的業(yè)務(wù)代碼里主動(dòng)調(diào)用realm.getAuthorizationCache().remove(userId);或者通過(guò)SecurityUtils.getSubject().logout()讓用戶(hù)重新登錄。方式很多沒(méi)有銀彈但你必須知道這個(gè)機(jī)制存在否則線(xiàn)上會(huì)出現(xiàn)“為什么我改了權(quán)限他還能訪(fǎng)問(wèn)”的詭異工單。3. 手寫(xiě)一個(gè)支持權(quán)限的 Realm 授權(quán)實(shí)現(xiàn)3.1 一個(gè)夠用的權(quán)限數(shù)據(jù)模型先約定一套簡(jiǎn)單但真實(shí)的數(shù)據(jù)表用戶(hù)表sys_user、角色表sys_role、權(quán)限表sys_permission、用戶(hù)角色關(guān)系表sys_user_role、角色權(quán)限關(guān)系表sys_role_permission。權(quán)限表里的perm_code字段我強(qiáng)烈建議采用 Shiro 通配符風(fēng)格的字符串形如order:list order:detail order:create order:export system:user:resetPwd這種寫(xiě)法不是 Shiro 強(qiáng)制要求的但配合它默認(rèn)的WildcardPermission做字符串匹配時(shí)非常自然。order:*能匹配所有 order 下面的權(quán)限*:export能匹配所有模塊的導(dǎo)出操作寫(xiě)出類(lèi)似“所有模塊可查看”的規(guī)則也容易。角色表里的role_code則采用業(yè)務(wù)語(yǔ)義的標(biāo)識(shí)比如admin、operator、auditor。我還習(xí)慣加一個(gè)role_type字段區(qū)分“系統(tǒng)內(nèi)置角色”和“自定義角色”授權(quán)查詢(xún)時(shí)按需過(guò)濾。3.2 核心代碼doGetAuthorizationInfo 的完整實(shí)現(xiàn)下面這個(gè)UserRealm示例包含授權(quán)部分。為了演示清晰我假設(shè)認(rèn)證時(shí) principal 放的是SysUser對(duì)象該對(duì)象有g(shù)etId()返回用戶(hù)主鍵。public class UserRealm extends AuthorizingRealm { private UserService userService; private PermissionService permissionService; // 構(gòu)造方法注入省略 Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { // 1. 獲取當(dāng)前登錄用戶(hù) Object primary principals.getPrimaryPrincipal(); if (primary null) { return null; } SysUser user; if (primary instanceof SysUser) { user (SysUser) primary; } else { // 如果統(tǒng)一存的是 username需要反查用戶(hù) user userService.findByUsername(String.valueOf(primary)); } if (user null) { return null; } // 2. 查角色集合和權(quán)限集合 SetString roleCodes roleService.findRoleCodesByUserId(user.getId()); SetString permCodes permissionService.findPermCodesByUserId(user.getId()); // 3. 組裝授權(quán)信息 SimpleAuthorizationInfo info new SimpleAuthorizationInfo(); info.setRoles(roleCodes); info.setStringPermissions(permCodes); return info; } Override public String getName() { return userRealm; } }需要注意兩個(gè)小點(diǎn)第一principals.getPrimaryPrincipal()返回的類(lèi)型完全取決于認(rèn)證時(shí)SimpleAuthenticationInfo的第一個(gè)參數(shù)傳的是什么所以上面代碼做了類(lèi)型兼容處理。第二getName()方法在多個(gè) Realm 共存時(shí)要保證唯一因?yàn)?Shiro 可能用它區(qū)分不同的 Realm 緩存。3.3 權(quán)限字符串的匹配邏輯到底是怎樣工作的Shiro 的WildcardPermission把權(quán)限字符串按冒號(hào)分成多段每段內(nèi)可以用逗號(hào)表示“或”用*表示“任意”。比如order:list只匹配 order 模塊的 list 操作。order:list,detail匹配 order 模塊的 list 和 detail 兩個(gè)操作。order:*匹配 order 模塊下所有操作。*:export匹配所有模塊的 export 操作。用戶(hù)擁有的權(quán)限字符串集合和判斷時(shí)傳入的權(quán)限字符串做匹配時(shí)規(guī)則是“用戶(hù)權(quán)限要能覆蓋請(qǐng)求權(quán)限”。比如用戶(hù)擁有order:*他請(qǐng)求order:export匹配成功他請(qǐng)求product:export匹配失敗因?yàn)橛脩?hù)權(quán)限只有 order 段product 段完全不沾邊。這里有一個(gè)很常見(jiàn)的誤區(qū)有人會(huì)把“擁有 order:* 就以為能操作所有模塊”。記住*只在它所在的段里通配不會(huì)跨段。想要全局權(quán)限得寫(xiě)*:*:*或直接給用戶(hù)*。如果默認(rèn)的冒號(hào)多段規(guī)則滿(mǎn)足不了業(yè)務(wù)你可以自定義Permission實(shí)現(xiàn)類(lèi)再通過(guò)info.addObjectPermission(...)放進(jìn)去。自定義匹配邏輯的判斷入口是Permission.implies(Permission p)方法這里可以完全按業(yè)務(wù)規(guī)則來(lái)。不過(guò)絕大多數(shù)項(xiàng)目用默認(rèn)通配符已經(jīng)足夠我建議不要過(guò)度設(shè)計(jì)。3.4 把 Realm 注冊(cè)進(jìn) Shiro 配置現(xiàn)在把自定義 Realm 配置到 Spring Boot 項(xiàng)目中。我這里給出一個(gè)基于配置類(lèi)的寫(xiě)法這也是目前主流工程常用的方式Configuration public class ShiroConfig { Bean public UserRealm userRealm() { UserRealm realm new UserRealm(); realm.setCredentialsMatcher(hashedCredentialsMatcher()); realm.setAuthorizationCachingEnabled(true); realm.setAuthorizationCacheName(authorizationCache); return realm; } Bean public DefaultWebSecurityManager securityManager(UserRealm realm) { DefaultWebSecurityManager manager new DefaultWebSecurityManager(); manager.setRealm(realm); return manager; } }這里我特意把setAuthorizationCachingEnabled(true)和緩存名稱(chēng)寫(xiě)出來(lái)因?yàn)楹芏嗳?Spring Boot 集成 Shiro 時(shí)忘了開(kāi)啟緩存導(dǎo)致授權(quán)查詢(xún)高頻率打到數(shù)據(jù)庫(kù)。開(kāi)啟后配合 Redis 緩存可以大幅提升權(quán)限判斷性能但要注意緩存失效問(wèn)題這一點(diǎn)我在后面第 5 部分詳細(xì)說(shuō)。4. 授權(quán)生效后的驗(yàn)證與調(diào)試4.1 用單元測(cè)試驗(yàn)證授權(quán)結(jié)果授權(quán)邏輯寫(xiě)完后第一步不是啟動(dòng)整個(gè) Web 應(yīng)用去點(diǎn)按鈕而是寫(xiě)幾個(gè)快速驗(yàn)證用例。Shiro 提供了一套線(xiàn)程綁定 Subject 的機(jī)制在測(cè)試代碼里可以直接模擬一個(gè)帶權(quán)限的用戶(hù)public class UserRealmAuthorizeTest { Test public void testAdminCanExportOrder() { // 組裝授權(quán)信息用戶(hù)擁有 order:* 權(quán)限 SimpleAuthorizationInfo authInfo new SimpleAuthorizationInfo(); authInfo.addRole(admin); authInfo.addStringPermission(order:*); // 構(gòu)造一個(gè)綁定 Subject 的 SecurityManager Realm realm mockRealmWithAuthInfo(authInfo); // 使用 Shiro 提供的測(cè)試工具認(rèn)證一個(gè)假用戶(hù) Subject subject new Subject.Builder(securityManager).buildSubject(); subject.login(new UsernamePasswordToken(tester, 123456)); // 斷言權(quán)限判斷結(jié)果 assertTrue(subject.isPermitted(order:export)); assertFalse(subject.isPermitted(product:delete)); } }這種測(cè)試的價(jià)值在于它不依賴(lài)數(shù)據(jù)庫(kù)直接驗(yàn)證 Shiro 匹配邏輯是否符合預(yù)期。如果你改了權(quán)限字符串格式跑一遍測(cè)試馬上知道有沒(méi)有破壞舊規(guī)則。注意mockRealmWithAuthInfo是測(cè)試輔助方法大概思路是自定義一個(gè) Realm 把a(bǔ)uthInfo固定返回這樣doGetAuthorizationInfo就不會(huì)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)。4.2 調(diào)試時(shí)如何觀察授權(quán)數(shù)據(jù)是否加載實(shí)際遇到“某個(gè)接口明明配置了權(quán)限注解卻 401/403”時(shí)最痛苦的是不知道“用戶(hù)到底有沒(méi)有這個(gè)權(quán)限”。我的習(xí)慣是先開(kāi) DEBUG 日志觀察LoggingSubject或自定義攔截器打印的 principal 和權(quán)限字符串。具體操作上可以在doGetAuthorizationInfo臨時(shí)打印一下查出來(lái)的角色和權(quán)限集合log.debug(用戶(hù) {} 的角色: {}, user.getUsername(), roleCodes); log.debug(用戶(hù) {} 的權(quán)限: {}, user.getUsername(), permCodes);然后調(diào)用權(quán)限判斷的地方也打印一下請(qǐng)求權(quán)限log.debug(判斷權(quán)限: {}, permission);兩端日志一對(duì)照問(wèn)題大概率立刻暴露要么是權(quán)限沒(méi)查到要么是權(quán)限字符串格式不對(duì)。舉個(gè)例子數(shù)據(jù)庫(kù)權(quán)限表里存的是order:export代碼里注解寫(xiě)的是RequiresPermissions(order:export)理論上沒(méi)問(wèn)題但如果權(quán)限表里存成了order_export或者export那永遠(yuǎn)匹配不上。這種問(wèn)題靠眼睛看數(shù)據(jù)庫(kù)就能快速定位。4.3 授權(quán)在三個(gè)業(yè)務(wù)層的落地姿勢(shì)Realm 提供的權(quán)限數(shù)據(jù)是地基但最終要作用到業(yè)務(wù)的三個(gè)位置第一層是 URL 過(guò)濾。在ShiroFilterFactoryBean里配置filterChainDefinitionMap比如/order/** perms[order:list]請(qǐng)求沒(méi)經(jīng)過(guò) URL 層就攔截掉。這層適合做粗粒度模塊控制。第二層是方法注解。用RequiresRoles(admin)、RequiresPermissions(order:export)標(biāo)記在 Controller 方法或 Service 方法上適合做細(xì)粒度操作控制。注意注解默認(rèn)是 AOP 攔截工作需要配置AuthorizationAttributeSourceAdvisor才能生效。第三層是頁(yè)面標(biāo)簽。JSP 環(huán)境下可以用shiro:hasPermission nameorder:exportVue 這類(lèi)前后端分離項(xiàng)目則往往由后端接口返回權(quán)限碼列表前端自己控制按鈕顯示。我見(jiàn)過(guò)很多項(xiàng)目在 URL 層和注解層重復(fù)配置同一套權(quán)限導(dǎo)致一條規(guī)則要改兩處。我的經(jīng)驗(yàn)是模塊級(jí)規(guī)則放 URL 層操作級(jí)規(guī)則放注解層不要重復(fù)攔截。權(quán)限碼列表通過(guò)接口返回給前端這樣三層的權(quán)限來(lái)源統(tǒng)一不至于各寫(xiě)一套。5. 生產(chǎn)環(huán)境中授權(quán)相關(guān)的常見(jiàn)坑與解法5.1 權(quán)限變更后用戶(hù)權(quán)限不更新的問(wèn)題這是授權(quán)功能上線(xiàn)后最常遇到的投訴“管理員給張三加了導(dǎo)出權(quán)限張三刷新頁(yè)面還是看不到導(dǎo)出按鈕”。原因前面說(shuō)過(guò)AuthorizingRealm開(kāi)了緩存后授權(quán)數(shù)據(jù)被快照在緩存里數(shù)據(jù)庫(kù)變更不會(huì)自動(dòng)推送給緩存。處理方案要看你的緩存介質(zhì)。如果用本地EhCache只能在權(quán)限變更時(shí)調(diào)realm.clearCachedAuthorizationInfo(principals)但要拿到用戶(hù)對(duì)應(yīng)的 principals 需要額外構(gòu)造。如果用 Redis推薦在權(quán)限變更服務(wù)里主動(dòng)刪除對(duì)應(yīng)用戶(hù)的 cache keykey 的命名規(guī)則要和你securityManager.setCacheManager(...)配置的序列化策略一致。我實(shí)際項(xiàng)目中更傾向的方案是授權(quán)緩存不用 Shiro 自帶的 CacheManager而是自己封裝一層回調(diào)。權(quán)限變更后通過(guò)消息隊(duì)列廣播一個(gè)用戶(hù) ID所有節(jié)點(diǎn)都刪除該用戶(hù)授權(quán)緩存。這樣既保證了多實(shí)例環(huán)境的一致性也不至于為了清緩存引入復(fù)雜的分布式鎖。5.2 多個(gè) Realm 協(xié)同工作時(shí)的授權(quán)合并陷阱有些系統(tǒng)會(huì)配置多個(gè) Realm比如一個(gè)UserRealm處理賬號(hào)密碼登錄一個(gè)TokenRealm處理免登令牌。此時(shí)ModularRealmAuthorizer的默認(rèn)行為是任何一個(gè) Realm 的授權(quán)數(shù)據(jù)命中即算通過(guò)。這帶來(lái)的一個(gè)奇怪現(xiàn)象是用戶(hù)能登錄但判權(quán)限時(shí) Shiro 同時(shí)問(wèn)兩個(gè) Realm 要授權(quán)數(shù)據(jù)。UserRealm里查不到角色的用戶(hù)請(qǐng)求subject.hasRole(admin)時(shí)TokenRealm如果也實(shí)現(xiàn)了doGetAuthorizationInfo并且返回了 admin 角色那這個(gè)用戶(hù)居然也能算作管理員。要處理這種隱患建議在doGetAuthorizationInfo里約束數(shù)據(jù)的適用范圍。最簡(jiǎn)單的方式是沒(méi)有用戶(hù)數(shù)據(jù)的 Realm 直接返回null或空AuthorizationInfo不要含糊地放一個(gè)空集合。另一個(gè)方式是重寫(xiě)ModularRealmAuthorizer的核心邏輯按 principal 來(lái)源區(qū)分我只認(rèn)某個(gè) realm 的數(shù)據(jù)。不過(guò)這個(gè)方案配置成本高大多數(shù)業(yè)務(wù)場(chǎng)景用“不越權(quán)返回?cái)?shù)據(jù)”就能規(guī)避。5.3 授權(quán)查詢(xún)頻繁打到數(shù)據(jù)庫(kù)權(quán)限判斷本身是高頻操作。登錄用戶(hù)每次刷新頁(yè)面可能要觸發(fā)幾十次isPermitted()如果你忘了開(kāi)緩存每一次都會(huì)進(jìn)doGetAuthorizationInfo。運(yùn)氣好命中慢查詢(xún)運(yùn)氣不好就是連接池打滿(mǎn)。排查方法很簡(jiǎn)單打開(kāi)數(shù)據(jù)庫(kù)慢查詢(xún)?nèi)罩居^察授權(quán) SQL 的執(zhí)行頻次。解決路徑分兩步第一步開(kāi)啟authorizationCachingEnabled第二步是給doGetAuthorizationInfo里的查詢(xún)加索引。sys_user_role和sys_role_permission兩張關(guān)聯(lián)表userId、roleId 字段必須有索引否則數(shù)據(jù)量上來(lái)必炸。5.4 權(quán)限字符串因大小寫(xiě)和空格匹配不上數(shù)據(jù)庫(kù)里權(quán)限碼不規(guī)范是家常便飯。有人存的是Order:Export有人復(fù)制時(shí)多了個(gè)空格Shiro 默認(rèn)的WildcardPermission做的是精確字符串拆分匹配大小寫(xiě)不同都算不匹配。想從源頭杜絕必須在權(quán)限維護(hù)頁(yè)面做輸入清洗統(tǒng)一轉(zhuǎn)小寫(xiě)、去掉兩側(cè)空格、限制只能使用字母數(shù)字冒號(hào)星號(hào)逗號(hào)。同時(shí)在doGetAuthorizationInfo里也做一次trim().toLowerCase()兜底。不要指望靠配置 Shiro 的WildcardPermission來(lái)做大小寫(xiě)忽略它沒(méi)有這個(gè)開(kāi)關(guān)。6. 權(quán)限設(shè)計(jì)層面的一些建議6.1 權(quán)限點(diǎn)細(xì)到操作角色粗到入口做完技術(shù)實(shí)現(xiàn)我更想聊聊權(quán)限模型設(shè)計(jì)這部分經(jīng)驗(yàn)在很多項(xiàng)目里比代碼更值錢(qián)。我見(jiàn)過(guò)兩種極端一種是把權(quán)限細(xì)到“看見(jiàn)訂單金額”這種字段級(jí)結(jié)果是權(quán)限表爆炸維護(hù)成本極高另一種是只有三四套角色一個(gè)“管理員”走天下結(jié)果業(yè)務(wù)根本沒(méi)法精細(xì)管控。平衡點(diǎn)通常是把權(quán)限點(diǎn)設(shè)計(jì)到“模塊操作”粒度比如order:export、user:resetPwd至于字段級(jí)的數(shù)據(jù)權(quán)限應(yīng)該通過(guò)查詢(xún)條件動(dòng)態(tài)過(guò)濾而不是塞進(jìn)權(quán)限框架。角色則盡量保持在個(gè)位數(shù)級(jí)別比如系統(tǒng)管理員、普通用戶(hù)、審計(jì)員、外部合作方。角色和權(quán)限之間是組合關(guān)系角色代表一種可授權(quán)的行為集合不要在系統(tǒng)里搞出幾百個(gè)組合角色。6.2 不要在業(yè)務(wù)代碼里硬編碼權(quán)限判斷雖然 Shiro 提供了subject.isPermitted()這種代碼級(jí)判斷但我不建議在業(yè)務(wù)方法里到處寫(xiě) if 硬編碼。硬編碼權(quán)限邏輯散落在各業(yè)務(wù)層等權(quán)限規(guī)則調(diào)整時(shí)你會(huì)陷入改代碼的噩夢(mèng)。我更推薦的做法是接口上用注解聲明所需權(quán)限統(tǒng)一由 AOP 攔截特殊場(chǎng)景比如同一個(gè)接口針對(duì)“本人”和“管理員”返回不同數(shù)據(jù)才在 Service 里顯式判斷并封裝一個(gè)PermissionChecker工具類(lèi)避免直接和 Subject API 耦合。這樣權(quán)限需求變更時(shí)大多數(shù)情況只需要調(diào)整數(shù)據(jù)庫(kù)權(quán)限配置不需要重新發(fā)版。6.3 從最小可用權(quán)限模型開(kāi)始迭代最后一條建議給剛開(kāi)始接觸 Shiro 的團(tuán)隊(duì)不要上來(lái)就設(shè)計(jì)五張表加一套復(fù)雜的動(dòng)態(tài)權(quán)限體系。先按“用戶(hù)-角色”二級(jí)模型跑通授權(quán)鏈路把doGetAuthorizationInfo的骨架搭好等業(yè)務(wù)真的出現(xiàn)“操作級(jí)精細(xì)管控”需求再加權(quán)限表、角色權(quán)限關(guān)聯(lián)表。安全框架的價(jià)值在于穩(wěn)定可靠地?cái)r住不該放行的人而不是一開(kāi)始就堆功能。我的經(jīng)驗(yàn)是框架本身的靈活度足夠支撐從簡(jiǎn)單到復(fù)雜的演進(jìn)。你先把授權(quán)通了后面加權(quán)限點(diǎn)只是往數(shù)據(jù)庫(kù)里插幾行數(shù)據(jù)的事完全不用改架構(gòu)。這個(gè)系列走到第十篇自定義 Realm 的授權(quán)部分算是徹底講透了。從定位到實(shí)現(xiàn)再到排坑該注意的地方都標(biāo)注了。如果你正在改造老項(xiàng)目的權(quán)限模塊建議先按第 5 部分的幾個(gè)坑對(duì)照一下現(xiàn)有代碼往往能少熬好幾個(gè)夜。 Java Shiro自定義Realm實(shí)現(xiàn)授權(quán)：從原理到權(quán)限數(shù)據(jù)模型實(shí)踐
Java Shiro 安全框架十自定義 Realm 實(shí)現(xiàn)授權(quán)做了幾個(gè) Shiro 項(xiàng)目之后我發(fā)現(xiàn)很多同學(xué)對(duì)“登錄成功”這件事特別上心但對(duì)“登錄之后能干什么”往往只有一個(gè)模糊概念反正登錄進(jìn)去了頁(yè)面上的按鈕該不該顯示、接口該不該讓調(diào)、數(shù)據(jù)該不該讓看這些才是一個(gè)安全框架真正值錢(qián)的地方。Shiro 的授權(quán)Authorization能力雖然接口簡(jiǎn)單但要把權(quán)限數(shù)據(jù)從數(shù)據(jù)庫(kù)里撈出來(lái)、裝進(jìn)框架能識(shí)別的結(jié)構(gòu)、再讓注解和標(biāo)簽正常工作中間的關(guān)鍵節(jié)點(diǎn)就是“自定義 Realm”。這篇文章我打算只講授權(quán)這一半。默認(rèn)你已經(jīng)跑通了認(rèn)證Authentication知道 Realm 是 Shiro 連接數(shù)據(jù)源的那座橋。我們順著這座橋繼續(xù)往前走把doGetAuthorizationInfo這個(gè)方法的里里外外都拆一遍從數(shù)據(jù)模型設(shè)計(jì)、代碼實(shí)現(xiàn)、調(diào)試驗(yàn)證到生產(chǎn)環(huán)境最容易踩的緩存和權(quán)限串號(hào)問(wèn)題一次說(shuō)清楚。1. 自定義 Realm 在 Shiro 授權(quán)中的定位1.1 授權(quán)和認(rèn)證是兩套獨(dú)立的動(dòng)作很多人第一次接觸 Shiro 時(shí)會(huì)以為“登錄數(shù)據(jù)都從數(shù)據(jù)庫(kù)查了順手把權(quán)限也查出來(lái)不就行了”。邏輯上沒(méi)問(wèn)題但 Shiro 的設(shè)計(jì)把這兩件事拆得很干凈認(rèn)證回答“你是誰(shuí)”授權(quán)回答“你能干什么”。這兩件事在代碼層面分別對(duì)應(yīng) Realm 里的兩個(gè)方法——doGetAuthenticationInfo和doGetAuthorizationInfo。之所以非要拆開(kāi)是因?yàn)槭跈?quán)判斷發(fā)生的時(shí)機(jī)遠(yuǎn)比登錄時(shí)多。用戶(hù)登錄時(shí)你當(dāng)然可以查出他所有角色權(quán)限并塞進(jìn) Session但真實(shí)系統(tǒng)里權(quán)限經(jīng)常變化管理員給用戶(hù)加了個(gè)角色、用戶(hù)被移出了某個(gè)部門(mén)、權(quán)限菜單被調(diào)整。如果只在登錄時(shí)查一次那這些變更只能等用戶(hù)重新登錄才生效太不靈活。Shiro 的做法是每次執(zhí)行subject.isPermitted()或subject.hasRole()時(shí)動(dòng)態(tài)向 Realm 要一次授權(quán)數(shù)據(jù)再配合緩存把性能問(wèn)題解決掉。所以自定義 Realm 的授權(quán)部分本質(zhì)上就是實(shí)現(xiàn)一個(gè)“按用戶(hù)查角色和權(quán)限”的查詢(xún)器。你的業(yè)務(wù)邏輯再?gòu)?fù)雜最終都得收斂到給它返回一個(gè)AuthorizationInfo。1.2 內(nèi)置 Realm 的授權(quán)能力為什么不夠用Shiro 自帶了好幾款開(kāi)箱即用的 Realm比如IniRealm、PropertiesRealm、JdbcRealm。其中JdbcRealm最容易被拿來(lái)直接對(duì)接數(shù)據(jù)庫(kù)它默認(rèn)的權(quán)限查詢(xún) SQL 是這樣的select role_name from user_roles where username ?以及select permission from roles_permissions where role_name ?這套表結(jié)構(gòu)設(shè)計(jì)的初衷是“一個(gè)用戶(hù)直接關(guān)聯(lián)角色角色直接關(guān)聯(lián)權(quán)限”簡(jiǎn)單直接。但真實(shí)業(yè)務(wù)表很少長(zhǎng)這樣常見(jiàn)情況是用戶(hù)表、角色表、用戶(hù)角色關(guān)聯(lián)表、權(quán)限表、角色權(quán)限關(guān)聯(lián)表五張表起步而且用戶(hù)名可能是郵箱、手機(jī)號(hào)或企業(yè)內(nèi)部工號(hào)。你要是為了湊JdbcRealm的默認(rèn) SQL 去改業(yè)務(wù)表結(jié)構(gòu)那純粹是本末倒置。更關(guān)鍵的是JdbcRealm默認(rèn)權(quán)限模型過(guò)于扁平它無(wú)法表達(dá)層級(jí)權(quán)限也沒(méi)法讓你在權(quán)限數(shù)據(jù)里塞入自定義的過(guò)濾條件。所以項(xiàng)目的通用做法是把AuthorizingRealm拿過(guò)來(lái)繼承自己寫(xiě)查詢(xún)邏輯。這就是“自定義 Realm 實(shí)現(xiàn)授權(quán)”這個(gè)主題存在的根本原因。1.3 一條權(quán)限判斷背后的完整調(diào)用鏈我習(xí)慣在講代碼前先讓讀者腦子里有一張調(diào)用圖。你寫(xiě)業(yè)務(wù)代碼時(shí)只調(diào)了一句if (subject.isPermitted(order:export)) { // 允許導(dǎo)出訂單 }這一句話(huà)背后發(fā)生了什么完整鏈路大致是這樣Subject委托給SecurityManager。SecurityManager繼續(xù)傳給Authorizer默認(rèn)實(shí)現(xiàn)是ModularRealmAuthorizer。ModularRealmAuthorizer遍歷當(dāng)前 SecurityManager 里注冊(cè)的所有 Realm逐個(gè)詢(xún)問(wèn)realm.isPermitted(principal, permission)。每個(gè) Realm 內(nèi)部會(huì)先檢查緩存沒(méi)有緩存就調(diào)用doGetAuthorizationInfo(principalCollection)加載授權(quán)數(shù)據(jù)。授權(quán)數(shù)據(jù)拿到后和當(dāng)前要判斷的Permission做匹配返回 boolean。有意思的是第三步ModularRealmAuthorizer會(huì)“遍歷所有 Realm 并一票制決定結(jié)果”。這是什么意思只要有一個(gè) Realm 說(shuō)“允許”整個(gè)判斷結(jié)果就是允許。這意味著如果你同時(shí)配置了多個(gè) Realm哪怕某個(gè) Realm 里壓根查不到這個(gè)用戶(hù)的權(quán)限只要另一個(gè) Realm 查到了授權(quán)請(qǐng)求依然能通過(guò)。這個(gè)小細(xì)節(jié)在生產(chǎn)環(huán)境里會(huì)帶來(lái)一些詭異現(xiàn)象后面我會(huì)專(zhuān)門(mén)講。2. 從 AuthorizingRealm 切入授權(quán)的骨架2.1 doGetAuthorizationInfo 是唯一的核心入口AuthorizingRealm這個(gè)抽象類(lèi)幫我們做了大量模板化工作。它繼承自AuthenticatingRealm在認(rèn)證能力基礎(chǔ)上擴(kuò)展了授權(quán)能力。我們要實(shí)現(xiàn)的方法只有一個(gè)protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals)參數(shù)PrincipalCollection里裝著用戶(hù)身份標(biāo)識(shí)。別小看這個(gè)參數(shù)它可能包含多個(gè) Realm 各自返回的 principal所以你在取用戶(hù)標(biāo)識(shí)時(shí)不能想當(dāng)然用principals.getPrimaryPrincipal()要看你認(rèn)證時(shí)SimpleAuthenticationInfo里到底放的是什么對(duì)象。返回的AuthorizationInfo就是授權(quán)數(shù)據(jù)的容器最常用的實(shí)現(xiàn)類(lèi)是SimpleAuthorizationInfo它內(nèi)部維護(hù)了三類(lèi)數(shù)據(jù)方法作用常見(jiàn)用法addRole(String)添加單個(gè)角色標(biāo)識(shí)info.addRole(admin)addRoles(SetString)批量添加角色從數(shù)據(jù)庫(kù)查詢(xún)結(jié)果直接放入addStringPermission(String)添加字符串權(quán)限info.addStringPermission(order:export)addObjectPermission(Permission)添加對(duì)象權(quán)限自定義 Permission 實(shí)現(xiàn)時(shí)使用很多初學(xué)者會(huì)糾結(jié)“角色和權(quán)限到底往哪個(gè)里面放”。我的建議是角色照常放權(quán)限也照常放兩者并不沖突。角色用于粗粒度的功能入口控制權(quán)限用于細(xì)粒度的操作控制后面會(huì)展開(kāi)講。2.2 授權(quán)數(shù)據(jù)該從哪里來(lái)doGetAuthorizationInfo方法體里面一般就三步拿用戶(hù)標(biāo)識(shí)、查數(shù)據(jù)庫(kù)、組裝AuthorizationInfo。真正的業(yè)務(wù)復(fù)雜點(diǎn)全在第二步。這里我要強(qiáng)調(diào)一個(gè)容易被忽視的設(shè)計(jì)問(wèn)題授權(quán)查詢(xún)到底應(yīng)該按用戶(hù)主鍵查還是按用戶(hù)名查如果認(rèn)證時(shí)你往 principal 里塞的是用戶(hù)主鍵userId那授權(quán)查詢(xún)就用userId做條件。如果塞的是用戶(hù)名就按用戶(hù)名查。兩種都可以但我更推薦主鍵因?yàn)橛脩?hù)名可能被修改而且即使兩個(gè)用戶(hù)同一天注冊(cè)、同名主鍵也不會(huì)撞。唯一的注意點(diǎn)是Subject的 API 大多接收 principal 作為參數(shù)你從principals.getPrimaryPrincipal()取出來(lái)的類(lèi)型必須和你放進(jìn)去時(shí)一致否則要做類(lèi)型判斷再轉(zhuǎn)換。至于查詢(xún)結(jié)果我也順手說(shuō)一個(gè)實(shí)踐不要在doGetAuthorizationInfo里一次只查角色另一次只查權(quán)限最好一條查詢(xún)把用戶(hù)的角色碼列表查出來(lái)再用角色集合去查權(quán)限集合。這樣可以減少數(shù)據(jù)庫(kù)交互次數(shù)。很多同學(xué)在緩存沒(méi)生效的開(kāi)發(fā)階段會(huì)反復(fù)看到 SQL 日志里授權(quán)查詢(xún)刷屏通常就是這里多查了幾趟。2.3 授權(quán)緩存Shiro 替你省了多少事AuthorizingRealm內(nèi)置了授權(quán)緩存。默認(rèn)情況下緩存是關(guān)閉的你需要設(shè)置authorizationCachingEnabled true并提供一個(gè)CacheManager。如果什么都不配每一次isPermitted()判斷都會(huì)真實(shí)觸發(fā)doGetAuthorizationInfo查詢(xún)數(shù)據(jù)庫(kù)性能上是災(zāi)難。這里的坑在于緩存默認(rèn) key 是AuthorizationCacheKey基于 principal 計(jì)算。什么意思呢用戶(hù) A 的權(quán)限被緩存后如果管理員修改了 A 的權(quán)限再判斷A.isPermitted(...)時(shí) Shiro 不會(huì)主動(dòng)知道你數(shù)據(jù)庫(kù)變了它只會(huì)從緩存里取出舊數(shù)據(jù)。這就是“權(quán)限變更后不生效”的經(jīng)典問(wèn)題。解決思路有兩個(gè)一是使用像 Redis 這樣的分布式緩存并主動(dòng)清理 key二是實(shí)現(xiàn)一個(gè)帶版本號(hào)的緩存策略。最省事的辦法是在權(quán)限變更的業(yè)務(wù)代碼里主動(dòng)調(diào)用realm.getAuthorizationCache().remove(userId);或者通過(guò)SecurityUtils.getSubject().logout()讓用戶(hù)重新登錄。方式很多沒(méi)有銀彈但你必須知道這個(gè)機(jī)制存在否則線(xiàn)上會(huì)出現(xiàn)“為什么我改了權(quán)限他還能訪(fǎng)問(wèn)”的詭異工單。3. 手寫(xiě)一個(gè)支持權(quán)限的 Realm 授權(quán)實(shí)現(xiàn)3.1 一個(gè)夠用的權(quán)限數(shù)據(jù)模型先約定一套簡(jiǎn)單但真實(shí)的數(shù)據(jù)表用戶(hù)表sys_user、角色表sys_role、權(quán)限表sys_permission、用戶(hù)角色關(guān)系表sys_user_role、角色權(quán)限關(guān)系表sys_role_permission。權(quán)限表里的perm_code字段我強(qiáng)烈建議采用 Shiro 通配符風(fēng)格的字符串形如order:list order:detail order:create order:export system:user:resetPwd這種寫(xiě)法不是 Shiro 強(qiáng)制要求的但配合它默認(rèn)的WildcardPermission做字符串匹配時(shí)非常自然。order:*能匹配所有 order 下面的權(quán)限*:export能匹配所有模塊的導(dǎo)出操作寫(xiě)出類(lèi)似“所有模塊可查看”的規(guī)則也容易。角色表里的role_code則采用業(yè)務(wù)語(yǔ)義的標(biāo)識(shí)比如admin、operator、auditor。我還習(xí)慣加一個(gè)role_type字段區(qū)分“系統(tǒng)內(nèi)置角色”和“自定義角色”授權(quán)查詢(xún)時(shí)按需過(guò)濾。3.2 核心代碼doGetAuthorizationInfo 的完整實(shí)現(xiàn)下面這個(gè)UserRealm示例包含授權(quán)部分。為了演示清晰我假設(shè)認(rèn)證時(shí) principal 放的是SysUser對(duì)象該對(duì)象有g(shù)etId()返回用戶(hù)主鍵。public class UserRealm extends AuthorizingRealm { private UserService userService; private PermissionService permissionService; // 構(gòu)造方法注入省略 Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { // 1. 獲取當(dāng)前登錄用戶(hù) Object primary principals.getPrimaryPrincipal(); if (primary null) { return null; } SysUser user; if (primary instanceof SysUser) { user (SysUser) primary; } else { // 如果統(tǒng)一存的是 username需要反查用戶(hù) user userService.findByUsername(String.valueOf(primary)); } if (user null) { return null; } // 2. 查角色集合和權(quán)限集合 SetString roleCodes roleService.findRoleCodesByUserId(user.getId()); SetString permCodes permissionService.findPermCodesByUserId(user.getId()); // 3. 組裝授權(quán)信息 SimpleAuthorizationInfo info new SimpleAuthorizationInfo(); info.setRoles(roleCodes); info.setStringPermissions(permCodes); return info; } Override public String getName() { return userRealm; } }需要注意兩個(gè)小點(diǎn)第一principals.getPrimaryPrincipal()返回的類(lèi)型完全取決于認(rèn)證時(shí)SimpleAuthenticationInfo的第一個(gè)參數(shù)傳的是什么所以上面代碼做了類(lèi)型兼容處理。第二getName()方法在多個(gè) Realm 共存時(shí)要保證唯一因?yàn)?Shiro 可能用它區(qū)分不同的 Realm 緩存。3.3 權(quán)限字符串的匹配邏輯到底是怎樣工作的Shiro 的WildcardPermission把權(quán)限字符串按冒號(hào)分成多段每段內(nèi)可以用逗號(hào)表示“或”用*表示“任意”。比如order:list只匹配 order 模塊的 list 操作。order:list,detail匹配 order 模塊的 list 和 detail 兩個(gè)操作。order:*匹配 order 模塊下所有操作。*:export匹配所有模塊的 export 操作。用戶(hù)擁有的權(quán)限字符串集合和判斷時(shí)傳入的權(quán)限字符串做匹配時(shí)規(guī)則是“用戶(hù)權(quán)限要能覆蓋請(qǐng)求權(quán)限”。比如用戶(hù)擁有order:*他請(qǐng)求order:export匹配成功他請(qǐng)求product:export匹配失敗因?yàn)橛脩?hù)權(quán)限只有 order 段product 段完全不沾邊。這里有一個(gè)很常見(jiàn)的誤區(qū)有人會(huì)把“擁有 order:* 就以為能操作所有模塊”。記住*只在它所在的段里通配不會(huì)跨段。想要全局權(quán)限得寫(xiě)*:*:*或直接給用戶(hù)*。如果默認(rèn)的冒號(hào)多段規(guī)則滿(mǎn)足不了業(yè)務(wù)你可以自定義Permission實(shí)現(xiàn)類(lèi)再通過(guò)info.addObjectPermission(...)放進(jìn)去。自定義匹配邏輯的判斷入口是Permission.implies(Permission p)方法這里可以完全按業(yè)務(wù)規(guī)則來(lái)。不過(guò)絕大多數(shù)項(xiàng)目用默認(rèn)通配符已經(jīng)足夠我建議不要過(guò)度設(shè)計(jì)。3.4 把 Realm 注冊(cè)進(jìn) Shiro 配置現(xiàn)在把自定義 Realm 配置到 Spring Boot 項(xiàng)目中。我這里給出一個(gè)基于配置類(lèi)的寫(xiě)法這也是目前主流工程常用的方式Configuration public class ShiroConfig { Bean public UserRealm userRealm() { UserRealm realm new UserRealm(); realm.setCredentialsMatcher(hashedCredentialsMatcher()); realm.setAuthorizationCachingEnabled(true); realm.setAuthorizationCacheName(authorizationCache); return realm; } Bean public DefaultWebSecurityManager securityManager(UserRealm realm) { DefaultWebSecurityManager manager new DefaultWebSecurityManager(); manager.setRealm(realm); return manager; } }這里我特意把setAuthorizationCachingEnabled(true)和緩存名稱(chēng)寫(xiě)出來(lái)因?yàn)楹芏嗳?Spring Boot 集成 Shiro 時(shí)忘了開(kāi)啟緩存導(dǎo)致授權(quán)查詢(xún)高頻率打到數(shù)據(jù)庫(kù)。開(kāi)啟后配合 Redis 緩存可以大幅提升權(quán)限判斷性能但要注意緩存失效問(wèn)題這一點(diǎn)我在后面第 5 部分詳細(xì)說(shuō)。4. 授權(quán)生效后的驗(yàn)證與調(diào)試4.1 用單元測(cè)試驗(yàn)證授權(quán)結(jié)果授權(quán)邏輯寫(xiě)完后第一步不是啟動(dòng)整個(gè) Web 應(yīng)用去點(diǎn)按鈕而是寫(xiě)幾個(gè)快速驗(yàn)證用例。Shiro 提供了一套線(xiàn)程綁定 Subject 的機(jī)制在測(cè)試代碼里可以直接模擬一個(gè)帶權(quán)限的用戶(hù)public class UserRealmAuthorizeTest { Test public void testAdminCanExportOrder() { // 組裝授權(quán)信息用戶(hù)擁有 order:* 權(quán)限 SimpleAuthorizationInfo authInfo new SimpleAuthorizationInfo(); authInfo.addRole(admin); authInfo.addStringPermission(order:*); // 構(gòu)造一個(gè)綁定 Subject 的 SecurityManager Realm realm mockRealmWithAuthInfo(authInfo); // 使用 Shiro 提供的測(cè)試工具認(rèn)證一個(gè)假用戶(hù) Subject subject new Subject.Builder(securityManager).buildSubject(); subject.login(new UsernamePasswordToken(tester, 123456)); // 斷言權(quán)限判斷結(jié)果 assertTrue(subject.isPermitted(order:export)); assertFalse(subject.isPermitted(product:delete)); } }這種測(cè)試的價(jià)值在于它不依賴(lài)數(shù)據(jù)庫(kù)直接驗(yàn)證 Shiro 匹配邏輯是否符合預(yù)期。如果你改了權(quán)限字符串格式跑一遍測(cè)試馬上知道有沒(méi)有破壞舊規(guī)則。注意mockRealmWithAuthInfo是測(cè)試輔助方法大概思路是自定義一個(gè) Realm 把a(bǔ)uthInfo固定返回這樣doGetAuthorizationInfo就不會(huì)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)。4.2 調(diào)試時(shí)如何觀察授權(quán)數(shù)據(jù)是否加載實(shí)際遇到“某個(gè)接口明明配置了權(quán)限注解卻 401/403”時(shí)最痛苦的是不知道“用戶(hù)到底有沒(méi)有這個(gè)權(quán)限”。我的習(xí)慣是先開(kāi) DEBUG 日志觀察LoggingSubject或自定義攔截器打印的 principal 和權(quán)限字符串。具體操作上可以在doGetAuthorizationInfo臨時(shí)打印一下查出來(lái)的角色和權(quán)限集合log.debug(用戶(hù) {} 的角色: {}, user.getUsername(), roleCodes); log.debug(用戶(hù) {} 的權(quán)限: {}, user.getUsername(), permCodes);然后調(diào)用權(quán)限判斷的地方也打印一下請(qǐng)求權(quán)限log.debug(判斷權(quán)限: {}, permission);兩端日志一對(duì)照問(wèn)題大概率立刻暴露要么是權(quán)限沒(méi)查到要么是權(quán)限字符串格式不對(duì)。舉個(gè)例子數(shù)據(jù)庫(kù)權(quán)限表里存的是order:export代碼里注解寫(xiě)的是RequiresPermissions(order:export)理論上沒(méi)問(wèn)題但如果權(quán)限表里存成了order_export或者export那永遠(yuǎn)匹配不上。這種問(wèn)題靠眼睛看數(shù)據(jù)庫(kù)就能快速定位。4.3 授權(quán)在三個(gè)業(yè)務(wù)層的落地姿勢(shì)Realm 提供的權(quán)限數(shù)據(jù)是地基但最終要作用到業(yè)務(wù)的三個(gè)位置第一層是 URL 過(guò)濾。在ShiroFilterFactoryBean里配置filterChainDefinitionMap比如/order/** perms[order:list]請(qǐng)求沒(méi)經(jīng)過(guò) URL 層就攔截掉。這層適合做粗粒度模塊控制。第二層是方法注解。用RequiresRoles(admin)、RequiresPermissions(order:export)標(biāo)記在 Controller 方法或 Service 方法上適合做細(xì)粒度操作控制。注意注解默認(rèn)是 AOP 攔截工作需要配置AuthorizationAttributeSourceAdvisor才能生效。第三層是頁(yè)面標(biāo)簽。JSP 環(huán)境下可以用shiro:hasPermission nameorder:exportVue 這類(lèi)前后端分離項(xiàng)目則往往由后端接口返回權(quán)限碼列表前端自己控制按鈕顯示。我見(jiàn)過(guò)很多項(xiàng)目在 URL 層和注解層重復(fù)配置同一套權(quán)限導(dǎo)致一條規(guī)則要改兩處。我的經(jīng)驗(yàn)是模塊級(jí)規(guī)則放 URL 層操作級(jí)規(guī)則放注解層不要重復(fù)攔截。權(quán)限碼列表通過(guò)接口返回給前端這樣三層的權(quán)限來(lái)源統(tǒng)一不至于各寫(xiě)一套。5. 生產(chǎn)環(huán)境中授權(quán)相關(guān)的常見(jiàn)坑與解法5.1 權(quán)限變更后用戶(hù)權(quán)限不更新的問(wèn)題這是授權(quán)功能上線(xiàn)后最常遇到的投訴“管理員給張三加了導(dǎo)出權(quán)限張三刷新頁(yè)面還是看不到導(dǎo)出按鈕”。原因前面說(shuō)過(guò)AuthorizingRealm開(kāi)了緩存后授權(quán)數(shù)據(jù)被快照在緩存里數(shù)據(jù)庫(kù)變更不會(huì)自動(dòng)推送給緩存。處理方案要看你的緩存介質(zhì)。如果用本地EhCache只能在權(quán)限變更時(shí)調(diào)realm.clearCachedAuthorizationInfo(principals)但要拿到用戶(hù)對(duì)應(yīng)的 principals 需要額外構(gòu)造。如果用 Redis推薦在權(quán)限變更服務(wù)里主動(dòng)刪除對(duì)應(yīng)用戶(hù)的 cache keykey 的命名規(guī)則要和你securityManager.setCacheManager(...)配置的序列化策略一致。我實(shí)際項(xiàng)目中更傾向的方案是授權(quán)緩存不用 Shiro 自帶的 CacheManager而是自己封裝一層回調(diào)。權(quán)限變更后通過(guò)消息隊(duì)列廣播一個(gè)用戶(hù) ID所有節(jié)點(diǎn)都刪除該用戶(hù)授權(quán)緩存。這樣既保證了多實(shí)例環(huán)境的一致性也不至于為了清緩存引入復(fù)雜的分布式鎖。5.2 多個(gè) Realm 協(xié)同工作時(shí)的授權(quán)合并陷阱有些系統(tǒng)會(huì)配置多個(gè) Realm比如一個(gè)UserRealm處理賬號(hào)密碼登錄一個(gè)TokenRealm處理免登令牌。此時(shí)ModularRealmAuthorizer的默認(rèn)行為是任何一個(gè) Realm 的授權(quán)數(shù)據(jù)命中即算通過(guò)。這帶來(lái)的一個(gè)奇怪現(xiàn)象是用戶(hù)能登錄但判權(quán)限時(shí) Shiro 同時(shí)問(wèn)兩個(gè) Realm 要授權(quán)數(shù)據(jù)。UserRealm里查不到角色的用戶(hù)請(qǐng)求subject.hasRole(admin)時(shí)TokenRealm如果也實(shí)現(xiàn)了doGetAuthorizationInfo并且返回了 admin 角色那這個(gè)用戶(hù)居然也能算作管理員。要處理這種隱患建議在doGetAuthorizationInfo里約束數(shù)據(jù)的適用范圍。最簡(jiǎn)單的方式是沒(méi)有用戶(hù)數(shù)據(jù)的 Realm 直接返回null或空AuthorizationInfo不要含糊地放一個(gè)空集合。另一個(gè)方式是重寫(xiě)ModularRealmAuthorizer的核心邏輯按 principal 來(lái)源區(qū)分我只認(rèn)某個(gè) realm 的數(shù)據(jù)。不過(guò)這個(gè)方案配置成本高大多數(shù)業(yè)務(wù)場(chǎng)景用“不越權(quán)返回?cái)?shù)據(jù)”就能規(guī)避。5.3 授權(quán)查詢(xún)頻繁打到數(shù)據(jù)庫(kù)權(quán)限判斷本身是高頻操作。登錄用戶(hù)每次刷新頁(yè)面可能要觸發(fā)幾十次isPermitted()如果你忘了開(kāi)緩存每一次都會(huì)進(jìn)doGetAuthorizationInfo。運(yùn)氣好命中慢查詢(xún)運(yùn)氣不好就是連接池打滿(mǎn)。排查方法很簡(jiǎn)單打開(kāi)數(shù)據(jù)庫(kù)慢查詢(xún)?nèi)罩居^察授權(quán) SQL 的執(zhí)行頻次。解決路徑分兩步第一步開(kāi)啟authorizationCachingEnabled第二步是給doGetAuthorizationInfo里的查詢(xún)加索引。sys_user_role和sys_role_permission兩張關(guān)聯(lián)表userId、roleId 字段必須有索引否則數(shù)據(jù)量上來(lái)必炸。5.4 權(quán)限字符串因大小寫(xiě)和空格匹配不上數(shù)據(jù)庫(kù)里權(quán)限碼不規(guī)范是家常便飯。有人存的是Order:Export有人復(fù)制時(shí)多了個(gè)空格Shiro 默認(rèn)的WildcardPermission做的是精確字符串拆分匹配大小寫(xiě)不同都算不匹配。想從源頭杜絕必須在權(quán)限維護(hù)頁(yè)面做輸入清洗統(tǒng)一轉(zhuǎn)小寫(xiě)、去掉兩側(cè)空格、限制只能使用字母數(shù)字冒號(hào)星號(hào)逗號(hào)。同時(shí)在doGetAuthorizationInfo里也做一次trim().toLowerCase()兜底。不要指望靠配置 Shiro 的WildcardPermission來(lái)做大小寫(xiě)忽略它沒(méi)有這個(gè)開(kāi)關(guān)。6. 權(quán)限設(shè)計(jì)層面的一些建議6.1 權(quán)限點(diǎn)細(xì)到操作角色粗到入口做完技術(shù)實(shí)現(xiàn)我更想聊聊權(quán)限模型設(shè)計(jì)這部分經(jīng)驗(yàn)在很多項(xiàng)目里比代碼更值錢(qián)。我見(jiàn)過(guò)兩種極端一種是把權(quán)限細(xì)到“看見(jiàn)訂單金額”這種字段級(jí)結(jié)果是權(quán)限表爆炸維護(hù)成本極高另一種是只有三四套角色一個(gè)“管理員”走天下結(jié)果業(yè)務(wù)根本沒(méi)法精細(xì)管控。平衡點(diǎn)通常是把權(quán)限點(diǎn)設(shè)計(jì)到“模塊操作”粒度比如order:export、user:resetPwd至于字段級(jí)的數(shù)據(jù)權(quán)限應(yīng)該通過(guò)查詢(xún)條件動(dòng)態(tài)過(guò)濾而不是塞進(jìn)權(quán)限框架。角色則盡量保持在個(gè)位數(shù)級(jí)別比如系統(tǒng)管理員、普通用戶(hù)、審計(jì)員、外部合作方。角色和權(quán)限之間是組合關(guān)系角色代表一種可授權(quán)的行為集合不要在系統(tǒng)里搞出幾百個(gè)組合角色。6.2 不要在業(yè)務(wù)代碼里硬編碼權(quán)限判斷雖然 Shiro 提供了subject.isPermitted()這種代碼級(jí)判斷但我不建議在業(yè)務(wù)方法里到處寫(xiě) if 硬編碼。硬編碼權(quán)限邏輯散落在各業(yè)務(wù)層等權(quán)限規(guī)則調(diào)整時(shí)你會(huì)陷入改代碼的噩夢(mèng)。我更推薦的做法是接口上用注解聲明所需權(quán)限統(tǒng)一由 AOP 攔截特殊場(chǎng)景比如同一個(gè)接口針對(duì)“本人”和“管理員”返回不同數(shù)據(jù)才在 Service 里顯式判斷并封裝一個(gè)PermissionChecker工具類(lèi)避免直接和 Subject API 耦合。這樣權(quán)限需求變更時(shí)大多數(shù)情況只需要調(diào)整數(shù)據(jù)庫(kù)權(quán)限配置不需要重新發(fā)版。6.3 從最小可用權(quán)限模型開(kāi)始迭代最后一條建議給剛開(kāi)始接觸 Shiro 的團(tuán)隊(duì)不要上來(lái)就設(shè)計(jì)五張表加一套復(fù)雜的動(dòng)態(tài)權(quán)限體系。先按“用戶(hù)-角色”二級(jí)模型跑通授權(quán)鏈路把doGetAuthorizationInfo的骨架搭好等業(yè)務(wù)真的出現(xiàn)“操作級(jí)精細(xì)管控”需求再加權(quán)限表、角色權(quán)限關(guān)聯(lián)表。安全框架的價(jià)值在于穩(wěn)定可靠地?cái)r住不該放行的人而不是一開(kāi)始就堆功能。我的經(jīng)驗(yàn)是框架本身的靈活度足夠支撐從簡(jiǎn)單到復(fù)雜的演進(jìn)。你先把授權(quán)通了后面加權(quán)限點(diǎn)只是往數(shù)據(jù)庫(kù)里插幾行數(shù)據(jù)的事完全不用改架構(gòu)。這個(gè)系列走到第十篇自定義 Realm 的授權(quán)部分算是徹底講透了。從定位到實(shí)現(xiàn)再到排坑該注意的地方都標(biāo)注了。如果你正在改造老項(xiàng)目的權(quán)限模塊建議先按第 5 部分的幾個(gè)坑對(duì)照一下現(xiàn)有代碼往往能少熬好幾個(gè)夜。