javascript
SpringBoot中使用Shiro和JWT做认证和鉴权
最近新做的項目中使用了shiro和jwt來做簡單的權限驗證,在和springboot集成的過程中碰到了不少坑。做完之后對shiro的體系架構了解的也差不多了,現在把中間需要注意的點放出來,給大家做個參考。
相對于spring security來說,shiro出來較早,框架也相對簡單。后面會另起一篇文章對這兩個框架做一個簡單的對比。
Shiro的關注點
首先看一下shiro中需要關注的幾個概念。
- SecurityManager,可以理解成控制中心,所有請求最終基本上都通過它來代理轉發,一般我們程序中不需要直接跟他打交道。
- Subject ,請求主體。比如登錄用戶,比如一個被授權的app。在程序中任何地方都可以通過SecurityUtils.getSubject()獲取到當前的subject。subject中可以獲取到Principal,這個是subject的標識,比如登陸用戶的用戶名或者id等,shiro不對值做限制。但是在登錄和授權過程中,程序需要通過principal來識別唯一的用戶。
- Realm,這個實在不知道怎么翻譯合適。通俗一點理解就是realm可以訪問安全相關數據,提供統一的數據封裝來給上層做數據校驗。shiro的建議是每種數據源定義一個realm,比如用戶數據存在數據庫可以使用JdbcRealm;存在屬性配置文件可以使用PropertiesRealm。一般我們使用shiro都使用自定義的realm。
當有多個realm存在的時候,shiro在做用戶校驗的時候會按照定義的策略來決定認證是否通過,shiro提供的可選策略有一個成功或者所有都成功等。
一個realm對應了一個CredentialsMatcher,用來做用戶提交認證信息和realm獲取得用戶信息做比對,shiro已經提供了常用的比如用戶密碼和存儲的Hash后的密碼的對比。
JWT的應用場景
關于JWT是什么,請參考JWT官網。這里就不多解釋了,可理解為使用帶簽名的token來做用戶和權限驗證,現在流行的公共開放接口用的OAuth 2.0協議基本也是類似的套路。這里只是說下選擇使用jwt不用session的原因。
首先,是要支持多端,一個api要支持H5, PC和APP三個前端,如果使用session的話對app不是很友好,而且session有跨域攻擊的問題。
其次,后端的服務是無狀態的,所以要支持分布式的權限校驗。當然這個不是主要原因了,因為session持久化在spring里面也就是加一行注解就解決的問題。不過,spring通過代理httpsession來做,總歸覺得有點復雜。
項目搭建
需求
需求相對簡單,1)支持用戶首次通過用戶名和密碼登錄;2)登錄后通過http header返回token;3)每次請求,客戶端需通過header將token帶回,用于權限校驗;4)服務端負責token的定期刷新,刷新后新的token仍然放到header中返給客戶端
pom.xml
這里使用了shiro的web starter。jwt是用的auth0的工具包,其實自己實現也比較簡單,我們這里就不自己重新造輪子了。
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.github.springboot</groupId><artifactId>shiro-jwt-demo</artifactId><version>1.0-SNAPSHOT</version><packaging>jar</packaging><name>Spring Boot with Shiro and JWT Demo</name><description>Demo project for Spring Boot with Shiro and JWT</description><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.0.4.RELEASE</version></parent><properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding><java.version>1.8</java.version><shiro.spring.version>1.4.0</shiro.spring.version><jwt.auth0.version>3.2.0</jwt.auth0.version></properties><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId></dependency><!-- 使用redis做數據緩存,如果不需要可不依賴 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><dependency><groupId>org.apache.shiro</groupId><artifactId>shiro-spring-boot-web-starter</artifactId><version>${shiro.spring.version}</version></dependency><dependency><groupId>com.auth0</groupId><artifactId>java-jwt</artifactId><version>${jwt.auth0.version}</version></dependency><dependency><groupId>org.apache.httpcomponents</groupId><artifactId>httpclient</artifactId><version>4.5.5</version></dependency><dependency><groupId>org.apache.commons</groupId><artifactId>commons-lang3</artifactId><version>3.7</version></dependency></dependencies><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><configuration><source>${java.version}</source><target>${java.version}</target></configuration></plugin><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><configuration><skipTests>true</skipTests></configuration></plugin></plugins></build> </project>shiro 配置
ShiroConfiguration
首先是初始化shiro的bean,主要是初始化Realm,注冊Filter,定義filterChain。這些配置的用處后面會逐漸講到。
校驗流程
我們使用Shiro主要做3件事情,1)用戶登錄時做用戶名密碼校驗;2)用戶登錄后收到請求時做JWT Token的校驗;3)用戶權限的校驗
登錄認證流程
登錄controller
從前面的ShiroFilterChainDefinition配置可以看出,對于登錄請求,Filter直接放過,進到controller里面。Controller會調用shiro做用戶名和密碼的校驗,成功后返回token。
登錄的Realm
從上面的controller實現我們看到,controller只負責封裝下參數,然后扔給Shiro了,這時候Shiro收到后,會到所有的realm中找能處理UsernamePasswordToken的Realm(我們這里是DbShiroRealm),然后交給Realm處理。Realm的實現一般直接繼承AuthorizingRealm即可,只需要實現兩個方法,doGetAuthenticationInfo()會在用戶驗證時被調用,我們看下實現。
我們可以看到doGetAuthenticationInfo里面只判斷了用戶存不存在,其實也沒做密碼比對,只是把數據庫的數據封裝一下就返回了。真正的比對邏輯在Matcher里實現的,這個shiro已經替我們實現了。如果matcher返回false,shiro會拋出異常,這樣controller那邊就會知道驗證失敗了。
登出
登出操作就比較簡單了,我們只需要把用戶登錄后保存的salt值清除,然后調用shiro的logout就可以了,shiro會將剩下的事情做完。
這樣整個登錄/登出就結束了,我們可以看到shiro對整個邏輯的拆解還是比較清楚的,各個模塊各司其職。
請求認證流程
請求認證的流程其實和登錄認證流程是比較相似的,因為我們的服務是無狀態的,所以每次請求帶來token,我們就是做了一次登錄操作。
JwtAuthFilter
首先我們先從入口的Filter開始。從AuthenticatingFilter繼承,重寫isAccessAllow方法,方法中調用父類executeLogin()。父類的這個方法首先會createToken(),然后調用shiro的Subject.login()方法。是不是跟LoginController中的邏輯很像。
JWT token封裝
在上面的Filter中我們創建了一個Token提交給了shiro,我們看下這個Token,其實很簡單,就是把jwt的token放在里面。
JWT Realm
Token有了,filter中也調用了shiro的login()方法了,下一步自然是Shiro把token提交到Realm中,獲取存儲的認證信息來做比對。
JWT Matcher
跟controller登錄不一樣,shiro并沒有實現JWT的Matcher,需要我們自己來實現。代碼如下:
這樣非登錄請求的認證處理邏輯也結束了,看起來是不是跟登錄邏輯差不多。其實對于無狀態服務來說,每次請求都相當于做了一次登錄操作,我們用session的時候之所以不需要做,是因為容器代替我們把這件事干掉了。
關于permissive
前面Filter里面的isAccessAllow方法,除了使用jwt token做了shiro的登錄認證之外,如果返回false還會額外調用isPermissive()方法。這里面干了什么呢?我們看下父類的方法:
邏輯很簡單,如果filter的攔截配置那里配置了permissive參數,即使登錄認證沒通過,因為isPermissive返回true,還是會讓請求繼續下去的。細心的同學或許已經發現我們之前shiroConfig里面的配置了,截取過來看一下:
chainDefinition.addPathDefinition("/logout", "noSessionCreation,authcToken[permissive]"); //做用戶認證,permissive參數的作用是當token無效時也允許請求訪問,不會返回鑒權未通過的錯誤就是這么簡單直接,字符串匹配。當然這里也可以重寫這個方法插入更復雜的邏輯。
這么做的目的是什么呢?因為有時候我們對待請求,并不都是非黑即白,比如登出操作,如果用戶帶的token是正確的,我們會將保存的用戶信息清除;如果帶的token是錯的,也沒關系,大不了不干啥,沒必要返回錯誤給用戶。還有一個典型的案例,比如我們閱讀博客,匿名用戶也是可以看的。只是如果是登錄用戶,我們會顯示額外的東西,比如是不是點過贊等。所以認證這里的邏輯就是token是對的,我會給把人認出來;是錯的,我也直接放過,留給controller來決定怎么區別對待。
JWT Token刷新
前面的Filter里面還有一個邏輯(是不是太多了??),就是如果用戶這次的token校驗通過后,我們還會順便看看token要不要刷新,如果需要刷新則將新的token放到header里面。
這樣做的目的是防止token丟了之后,別人可以拿著一直用。我們這里是固定時間刷新。安全性要求更高的系統可能每次請求都要求刷新,或者是每次POST,PUT等修改數據的請求后必須刷新。判斷邏輯如下:
以上就是jwt token校驗的所有邏輯了,是不是有點繞,畫一個流程圖出來,對比著看應該更清楚一點。
jwt filter邏輯
角色配置
認證講完了,下面看下訪問控制。對于角色檢查的攔截,是通過繼承一個AuthorizationFilter的Filter來實現的。Shiro提供了一個默認的實現RolesAuthorizationFilter,比如可以這么配置:
chainDefinition.addPathDefinition("/article/edit", "authc,role[admin]");表示要做文章的edit操作,需要滿足兩個條件,首先authc表示要通過用戶認證,這個我們上面已經講過了;其次要具備admin的角色。shiro是怎么做的呢?就是在請求進入這個filter后,shiro會調用所有配置的Realm獲取用戶的角色信息,然后和Filter中配置的角色做對比,對上了就可以通過了。
所以我們所有的Realm還要另外一個方法doGetAuthorizationInfo,不得不吐槽一下,realm里面要實現的這兩個方法的名字實在太像了。
在JWT Realm里面,因為沒有存儲角色信息,所以直接返回空就可以了:
在DbRealm里面,實現如下:
@Overrideprotected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {SimpleAuthorizationInfo simpleAuthorizationInfo = new SimpleAuthorizationInfo();UserDto user = (UserDto) principals.getPrimaryPrincipal();List<String> roles = user.getRoles();if(roles == null) {roles = userService.getUserRoles(user.getUserId());user.setRoles(roles);}if (roles != null)simpleAuthorizationInfo.addRoles(roles);return simpleAuthorizationInfo;}這里需要注意一下的就是Shiro默認不會緩存角色信息,所以這里調用service的方法獲取角色強烈建議從緩存中獲取。
自己實現RoleFilter
在實際的項目中,對同一個url多個角色都有訪問權限很常見,shiro默認的RoleFilter沒有提供支持,比如上面的配置,如果我們配置成下面這樣,那用戶必須同時具備admin和manager權限才能訪問,顯然這個是不合理的。
所以自己實現一個role filter,只要任何一個角色符合條件就通過,只需要重寫AuthorizationFilter中兩個方法就可以了:
public class AnyRolesAuthorizationFilter extends AuthorizationFilter {@Overrideprotected boolean isAccessAllowed(ServletRequest servletRequest, ServletResponse servletResponse, Object mappedValue) throws Exception {Subject subject = getSubject(servletRequest, servletResponse);String[] rolesArray = (String[]) mappedValue;if (rolesArray == null || rolesArray.length == 0) { //沒有角色限制,有權限訪問return true;}for (String role : rolesArray) {if (subject.hasRole(role)) //若當前用戶是rolesArray中的任何一個,則有權限訪問return true;}return false;}/*** 權限校驗失敗,錯誤處理*/@Overrideprotected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws IOException {HttpServletResponse httpResponse = WebUtils.toHttp(response);httpResponse.setCharacterEncoding("UTF-8");httpResponse.setContentType("application/json;charset=utf-8");httpResponse.setStatus(HttpStatus.SC_UNAUTHORIZED);return false;}}禁用session
因為用了jwt的訪問認證,所以要把默認session支持關掉。這里要做兩件事情,一個是ShiroConfig里面的配置:
@Beanprotected SessionStorageEvaluator sessionStorageEvaluator(){DefaultWebSessionStorageEvaluator sessionStorageEvaluator = new DefaultWebSessionStorageEvaluator();sessionStorageEvaluator.setSessionStorageEnabled(false);return sessionStorageEvaluator;}另外一個是在對請求加上noSessionCreationFilter,具體原因上面的代碼中已經有解釋,用法如下:
chainDefinition.addPathDefinition("/**", "noSessionCreation,authcToken");跨域支持
對于前后端分離的項目,一般都需要跨域訪問,這里需要做兩件事,一個是在JwtFilter的postHandle中在頭上加上跨域支持的選項(理論上應該重新定義一個Filter的,圖省事就讓它多干點吧??)。
@Overrideprotected void postHandle(ServletRequest request, ServletResponse response){this.fillCorsHeader(WebUtils.toHttp(request), WebUtils.toHttp(response));}在實際使用中發現,對于controller返回@ResponseBody的請求,filter中添加的header信息會丟失。對于這個問題spring已經給出解釋,并建議實現ResponseBodyAdvice類,并添加@ControllerAdvice。
public interface ResponseBodyAdvice
Allows customizing the response after the execution of an @ResponseBody or a ResponseEntity controller method but >before the body is written with an HttpMessageConverter.
Implementations may be registered directly with RequestMappingHandlerAdapter and ExceptionHandlerExceptionResolver or more likely annotated with @ControllerAdvice in which case they will be auto-detected by both.
所以如果存在返回@ResponseBody的controller,需要添加一個ResponseBodyAdvice實現類
@ControllerAdvice public class ResponseHeaderAdvice implements ResponseBodyAdvice<Object> {@Overridepublic boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) {return true;}@Overridepublic Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass,ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {ServletServerHttpRequest serverRequest = (ServletServerHttpRequest)serverHttpRequest;ServletServerHttpResponse serverResponse = (ServletServerHttpResponse)serverHttpResponse;if(serverRequest == null || serverResponse == null|| serverRequest.getServletRequest() == null || serverResponse.getServletResponse() == null) {return o;}// 對于未添加跨域消息頭的響應進行處理HttpServletRequest request = serverRequest.getServletRequest();HttpServletResponse response = serverResponse.getServletResponse();String originHeader = "Access-Control-Allow-Origin";if(!response.containsHeader(originHeader)) {String origin = request.getHeader("Origin");if(origin == null) {String referer = request.getHeader("Referer");if(referer != null)origin = referer.substring(0, referer.indexOf("/", 7));}response.setHeader("Access-Control-Allow-Origin", origin);}String allowHeaders = "Access-Control-Allow-Headers";if(!response.containsHeader(allowHeaders))response.setHeader(allowHeaders, request.getHeader(allowHeaders));String allowMethods = "Access-Control-Allow-Methods";if(!response.containsHeader(allowMethods))response.setHeader(allowMethods, "GET,POST,OPTIONS,HEAD");//這個很關鍵,要不然ajax調用時瀏覽器默認不會把這個token的頭屬性返給JSString exposeHeaders = "access-control-expose-headers";if(!response.containsHeader(exposeHeaders))response.setHeader(exposeHeaders, "x-auth-token");return o;} }好了,到這里使用shiro和jwt做用戶認證和鑒權的實現就結束了。
總結
以上是生活随笔為你收集整理的SpringBoot中使用Shiro和JWT做认证和鉴权的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Java基础day16
- 下一篇: Java基础day17