Session(数据)共享的前后端分离Shiro实战

1，前言

     本文期望描述如何使用Shiro构建基本的安全登录和权限验证。本文实战场景有如下特殊需求：1，在集群和分布式环境实现session共享；2，前端只使用HTML/CSS/JS。因此无法直接使用Shiro提供的SessionManager，以及Shiro针对web应用提供的Filter拦截方式。当然，除非是一定要通过共享缓存的方式共享session，否则还是使用Shiro默认的session管理，毕竟增加独立缓存就意味着维护成本的提高和可用性的下降。

 

2， Shiro架构

     首先一睹官方给出的Shiro架构图，如图1所示。刨除最右侧的加密工具类，主要围绕SercurityManager来阐述。SercurityManager是Shiro安全框架里的顶层安全管理中心，所有安全控制相关逻辑都是在SercurityManager里面通过delegate的方式，调用到真正的动作执行者。从图1可以清楚看到主要管理的组件：authentication管理，authorization管理，session管理，session缓存管理，cache管理，realms管理。(本文不想重复已有的文字，想要更好的了解Shiro，详见官方推荐的Shiro full intro: https://www.infoq.com/articles/apache-shiro)

     1）Shiro提供的CacheManager比较单薄，提供实现是MemoryConstrainedCacheManager，主要是依赖SoftHashMap来做基于内存条件的缓存，也即是当内存吃紧，没有新的内存空间来存放new出来的对象时，会去释放SoftHashMap中存放的对象，在本文中的应用场景是面向集群和分布式应用环境，使用了Redi缓存登录用户的相关信息，所以需要自定义cache处理。

     2）Shiro对于session的缓存管理，定义了SessionDAO抽象，并提供了两个存放于本地JVM内存的EnterpriseCacheSessionDAO和MemorySessionDAO，两者主要区别是EnterpriseCacheSessionDAO的session存放在SoftHashMap中，原则上可以自己实现SessionDAO 接口，实际存储使用Redis来做到完整的session共享，但是缺陷是：a，不安全，因为把所有数据都共享出去了；b，当每次需要获取session数据时，都需要通过网络来把整个session反序列化回来，而考虑很多情况下，只是间断的需要几个key的数据，这样在session数据量大一些的时候，就会产生大量消耗。因此在共享session时，不去替换默认SessionDao的实现，而是通过@overwrite AbstractNativeSessionManager getter/setter attribute方法，实现有选择的共享session的基本初始化和指定attribute key的数据。

     3）Shiro的authentication和authorization过程主要是依据用户定义的 AuthorizingRealm中提供的AuthenticationInfo和AuthorizationInfo。特别地，authentication 还提供类似验证链的authentication策略，允许用户提供多个Realm。第3部分会具体的示例Shiro集成Spring的使用范例，并详细解释AuthorizingRealm 。

 

图 1 Shiro官方架构图

3， Shiro使用范例

     官方提供了集成Spring Web应用的使用例子，但是就如前文提到的，这里前端只能使用JS的Http和后端通信，因此无法直接使用ShiroFilterFactoryBean来做Request的Filter。本文鉴于简单和初期的原则，可以选择定义一个RequestInterceptor类继承HandlerInterceptorAdapter并overwrite preHandle 方法。Interceptor的applicationContext和源码定义如下：

 

applicationContext.xml

 1 <mvc:interceptors>
 2     <mvc:interceptor>
 3         <mvc:mapping path="/**"/>
 4         
 5         <mvc:mapping path="/admin/**"/>
 6         
 7         <mvc:exclude-mapping path="/admin/login"/>
 8         <mvc:exclude-mapping path="/admin/code"/>
 9         <mvc:exclude-mapping path="/admin/logout"/>
10         <mvc:exclude-mapping path="/admin/msgErrorInfo"/>
11         
12         <bean class="authorizing.RequestInterceptor">
13             <property name="unauthenticatedUrl" value="/admin/msgErrorInfo" />
14         bean>
15     mvc:interceptor>
16 mvc:interceptors>

 

RequestInterceptor.java

 1 public class RequestInterceptor extends HandlerInterceptorAdapter {
 2  
 3     private String unauthenticatedUrl;
 4  
 5     public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
 6             Object handler) throws Exception {
 7         if(PermissionUtils.isLogin(request)){
 8             return true;
 9         }
10         //token已失效，返回提示信息
11         request.getRequestDispatcher(unauthenticatedUrl).forward(request, response);
12         return false;
13     }
14  
15     public void setUnauthenticatedUrl(String unauthenticatedUrl) {
16         this.unauthenticatedUrl = unauthenticatedUrl;
17     }
18 }

 

     RequestInterceptor.java定义非常简单，主要是在preHandler方法中验证了一下请求是否是登录用户发出的，否则响应给前端一个重定向。然后看一下PermissionUtils.isLogin(request)是怎样做登录验证的。

PermissionUtils.java

 1 public class PermissionUtils {
 2 private static ThreadLocal sessionToken = new ThreadLocal();
 3  
 4 public static boolean isLogin(HttpServletRequest request){
 5     String token = sessionToken(request);
 6     if(StringUtils.isEmpty(token))
 7         return false;
 8     /**
 9     * 使用token检查是否存在登录session
10     */
11     //Session session = SecurityUtils.getSecurityManager().getSession(new WebSessionKey(token, request, response));
12     Session session = SecurityUtils.getSecurityManager().getSession(new DefaultSessionKey(token));
13     if(session != null){
14         session.touch();
15         sessionToken.set(token);
16         return true;
17     }
18     return false;
19 }
20  
21 private static String sessionToken(HttpServletRequest request){
22     return request.getHeader("token");
23 }
24 }

 

     从PermissionUtils.java可以判断，保存前后端session的方式是通过token的形式。也即是每次request中的header部分都携带了登录成功后获取的token，以token为标识获取登录用户的session。特别地，对于Shiro而言，session并非特定于Web应用，Shiro有自己的session定义，可以独立于应用环境而存在。因此为了追求简单(既已弃用了Shiro针对web.xml应用提供的Filter)，直接使用Shiro创建的默认session(实际是SimpleSession)。此外，需要说明的一个细节是通过Shiro的SecurityManager 返回的session实际都是一个代理(DelegatingSession的实例)。因此，通过 SecurityManager获取的session，然后对session执行的动作实际都是通过 SecurityManager的SessionManager来完成的(因为共享session，每一次session的touch动作都应该反映到共享session中，后文，可以看到overwrite SessionManager#touch(SessionKey key)和start session)。Shiro提供的默认SessionManager都继承了AbstractValidatingSessionManager$sessionValidationSchedulerEnabled属性，该属性控制了是否执行一个后台守护线程(Thread#setDaemon(true))在给定的一个固定时间间隔(默认1个小时)内周期性的检查session是否过期，并且在每一次获取到session之后都会去检查session是否过期（对于共享session的集群，共享缓存基本都已具备超时管理功能，所以可以重新实现后文提到的 AbstractNativeSessionManager#getSession(SessionKey)）。PermissionUtils.java中定义了一个ThreadLocal类型的sessionToken变量，该变量是用于暂存当前request authentication成功之后的session标识，避免每次获取token都要从request中拿(后文中使用到的每一个url的authorization都需要首先执行一次checkPermission方法，通过token来验证是否有访问权限)。

    

     接下来描述Authentication和Authorization，具体地说明如何基于Shiro实现login和check permission。下面先给出applicationContext配置。

applicationContext.xml

<bean id="securityManager" class="org.apache.shiro.mgt.DefaultSecurityManager">
  <property name="realm" ref="authorizingRealm" />
  <property name="sessionManager">
      <bean class="service.authorizing.shiro.RedisSessionManager" >
        <property name="globalSessionTimeout" value="${session.timeout}" />
      bean>
  property>
bean>
<bean id="realmCache" class="service.authorizing.shiro.cache.RedisShiroCache" />
<bean id="authorizingRealm" class="service.authorizing.shiro.DefaultAuthorizingRealm">
  <property name="authorizationCachingEnabled" value="true"/>
  <property name="authorizationCache" ref="realmCache" />
bean>
<bean id="lifecycleBeanPostProcessor" class="org.apache.shiro.spring.LifecycleBeanPostProcessor"/>
 
<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
  <property name="staticMethod" value="org.apache.shiro.SecurityUtils.setSecurityManager"/>
  <property name="arguments" ref="securityManager"/>
bean>

 

     applicationContext.xml中配置的DefaultSecurityManager，RedisSessionManager，DefaultAuthorizingRealm和RedisShiroCache，分别代表Shiro的默认SecurityManager，自定义基于Redis的session manager，继承自Shiro的AuthorizingRealm的默认实现，以及自定义基于Redis的用户权限相关的Cache实现。注意到，本文的应用场景虽然是web.xml应用，但是并没有使用Shiro提供的 DefaultWebSecurityManager和DefaultWebSessionManager这两个针对web应用的拓展。使用针对web应用的拓展实现自然也没问题，但是个人认为对于纯粹的前后端分离权限认证的应用场景中，前端和后端应当是完全独立的，它们之间唯一的耦合是通过Http request交互的token。因此就目前简单和初期的原则，不需要DefaultWebSecurityManager和DefaultWebSessionManager。

 

图2 Shiro组件交互过程

     在讲解程序具体怎样执行login和check permission之前，先看图2所示的Shiro各组件的交互过程，可以看到Real是安全验证的依据。所以有必要先理解Shiro提供的abstract类AuthorizingRealm，该类定义了两个抽象方法doGetAuthorizationInfo和doGetAuthenticationInfo，分别用于check permission和login验证。具体如下DefaultAuthorizingRealm.java的定义：

 

DefaultAuthorizingRealm.java

 1 public class DefaultAuthorizingRealm extends AuthorizingRealm {
 2  
 3 @Autowired
 4 private AuthorizingService authorizingService;
 5  
 6     /**
 7     * 获取登录用户角色和功能权限信息，
 8     * 使用{@link org.apache.shiro.cache.CacheManager}和{@link org.apache.shiro.cache.Cache}获取数据.
 9     * @param principals 登录用户ID
10     * @return
11     */
12     protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
13         Object username =principals.getPrimaryPrincipal();
14         Cache infoCache = getAuthorizationCache();
15         AuthorizationInfo info = infoCache.get(username);
16         return info;
17     }
18  
19     /**
20     * 根据登录用户token,获取用户信息。
21     * 对于session timeout时间较短的场景可以考虑使用AuthenticationCache
22     * 若验证失败，会抛出异常 {@link AuthenticationException}
23     * @param token
24     * @return
25     * @throws AuthenticationException
26     */
27     protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
28         Object username = token.getPrincipal();
29         //对于session timeout时间较短的场景,可缓存用户authentication信息
30         //Cache infoCache = getAuthenticationCache();
31         //return infoCache.get(username);
32         return authorizingService.authentication(username);
33     }
34 }

 

     DefaultAuthorizingRealm.java的实现，可以看到用户只需要通过 doGetAuthorizationInfo和doGetAuthenticationInfo两个方法给Shiro的SecurityManager提供Authorization和Authentication信息，SecurityManager就会在执行check permission和login操作时自动调用这两个函数来验证操作。下面我们再看执行login和check permission操作时具体做了什么。

 

• Authentication

     下面在LoginController.java定义了login请求操作。

 

LoginController.java

 1 @Controller
 2 @RequestMapping("/admin")
 3 public class LoginController {
 4   Logger logger = LoggerFactory.getLogger(LoginController.class);
 5  
 6   @Autowired
 7   private AuthorizingService authorizingService;
 8  
 9   @RequestMapping("/login")
10   @ResponseBody
11   public LoginToken login(User user, HttpServletRequest request){
12       Subject subject = new Subject.Builder().buildSubject();
13       UsernamePasswordToken token = new UsernamePasswordToken(userName, UtilTool.md5Tool(password));
14       token.setRememberMe(true);
15       LoginToken loginToken = new LoginToken();
16       try{
17            subject.login(token);
18            Session session = subject.getSession();
19            user.setToken((String) session.getId());
20            loginToken.setResultCode(WebConstants.RESULT_SUCCESS_CODE);
21       } catch (AuthenticationException e) {
22            loginToken.setResultCode(WebConstants.RESULT_FAIL_CODE);
23            loginToken.setMessage("用户名或密码错误!");
24       }
25       return loginToken;
26   }
27 }

 

     上述login代码只做了非常简单用户名和密码的验证示例。可以看出login如果没有抛出AuthenticationExeception，则说明登录成功。

 

• Authorization

     访问权限控制需要在所有的访问controller的函数中配置，因此使用工具类最合适(在工具类的基础上做成spring annotation也可以很方便)，既是PermissionUtils.java。

 

PermissionUtils.java

 1 private static AuthorizingService authorizingService;
 2  
 3 private static ThreadLocal sessionToken = new ThreadLocal();
 4  
 5 /**
 6 *
 7 * @param url eg: /admin/review
 8 * @param argv eg: WAIT_BIZ_MANAGER
 9 */
10 public static void checkPermission(String url, @Nullable String argv){
11     Subject subject = getSubject();
12     String permissionCode = authorizingService.uriMappingCode(url, argv);
13     if(StringUtils.isEmpty(permissionCode))
14         throw new IllegalArgumentException("不明操作");
15     subject.checkPermission(permissionCode);
16 }
17  
18 public static Subject getSubject(){
19     String token = sessionToken.get();
20     if(StringUtils.isEmpty(token))
21         throw new AuthenticationException("未经认证");
22     return new Subject.Builder()
23             .sessionId(sessionToken.get())
24             .buildSubject();
25 }
26  
27 public static void setAuthorizingService(AuthorizingService authorizingService) {
28     PermissionUtils.authorizingService = authorizingService;
29 }

 

     从上述代码来看，每一个request的checkPermission操作，都需要依赖前文RequestInterceptor.java中提到的，从request中获取的token，并依赖该token找到缓存的session 。在权限控制的设计时，不同的业务场景可能需要不同粒度的权限控制，在这里做到了request参数级别的权限控制（在workflow应用中，一个流程涉及多个角色的参与，但很可能只抽象一个接口，如下文的/review操作）。在实现的时，灵活的方式是可以维护一张uri和permission_code之间的关系表(简单可以propertites文件)。对于前端用户而言，为了提升用户体验，拥有不同权限的用户得到的界面会有相应的隐藏和显示，因此会给前端的登录用户提供一张可访问权限表。在这里一个细节的设计，个人觉得有意义的是，在返回给前端的权限表的Key值不应当是permission_code,而是uri。因为permission_code对于前端而言毫无意义，而uri正是前后端沟通的桥梁。因此，check Permission操作可以如下：

 

ReviewApiController.java

 

 1 @RestController
 2 @RequestMapping(value = "/review")
 3 public class ReviewApiController {
 4  
 5     @Autowired
 6     private ReviewService reviewService;
 7  
 8     @ResponseBody
 9     @RequestMapping(value = "/review", method = POST)
10     public WebResult review(@RequestBody NewReviewVo reviewVo){
11         //检查访问权限
12         PermissionUtils.checkPermission("/review/review", reviewVo.getFeatureCode());
13         WebResult result = WebResult.successResult();
14         try {
15             Review review = ReviewAssembler.voToReview(reviewVo);
16             reviewService.review(review);
17         }catch (Exception e){
18             result = WebResult.failureResult(e.getMessage());
19         }
20         return result;
21     }
22 ｝

 

• SessionManager

     由于要实现有选择的共享session数据，因此session管理成了最棘手的问题，因为你不是粗暴地将整个session序列化到缓存并仍以local session的方式管理，其间需要额外得小心处理共享的session数据和本地的session数据。下面给出RedisSessionManager.java的实现：

 

RedisSessionManager.java

  1 /**
  2 * 根据 attributeKey，有选择的缓存session信息;
  3 * 设置 {@parm enabledSharedSessionData}来有选择的启用共享session功能。
  4 */
  5 public class RedisSessionManager extends DefaultSessionManager {
  6  
  7     private static Logger logger = LoggerFactory.getLogger(RedisSessionManager.class);
  8  
  9     private boolean enabledSharedSessionData;
 10  
 11     private Set sharedSessionDataKeys;
 12  
 13     public RedisSessionManager() {
 14         enabledSharedSessionData = true;
 15         sharedSessionDataKeys = new HashSet();
 16     }
 17  
 18     @Override
 19     public Collection