微服务架构 | 如何让接口权限继续继承下去？

Posted 码农架构

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务架构 | 如何让接口权限继续继承下去？相关的知识，希望对你有一定的参考价值。

导读：在访问系统某个或者某类接口后进行一系列权限校验，但在后续接口中我们想让访问权限一直授权下去改如何处理呢？总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。

权限继承意味着网站集中某个元素的权限设置将传递给该元素的子元素。这样，网站会从网站集的顶级 ("root") 网站继承权限，库继承自包含库的网站，等等。权限继承使您能够一次进行权限分配，并且拥有该权限应用于继承权限的所有网站、列表、库、文件夹和项目。此行为可降低网站集管理员和网站所有者在安全管理上所花的复杂性和时间。    

 

一、背景

在一次性能优化中发现，检查堆栈质摘要信息后，发现权限校验接口耗时高达 1.5s 以上还不涉及任何实例数据，但是对实例数据交叉查询较为频繁。针对这种场景需要对数据查询的接口做性能优化。

 

前后检查完后发现实例查询数据最大的瓶颈就是权限校验接口，其次就是实例查询接口。

 

如下面场景

 

 

在经过 1~6 请求并且完成闭环之后，如果我们需要继续通过⑥接口返回的实例的某些参数继续请求。

 

此时我们一帮两种解决思路

  • 在原有接口中继续优化参数，将需要第二次请求的入参和返回参数依次追加到同一个接口中

  • 新开发一个接口继续走权限校验和第一个接口实现步骤一样。

 

但这两种方案都合理么？

 

二、生成授权码

原理其实很简单，如我们单点登录认证中心颁发认证码授权访问各个系统一样的到底。怎么实现呢？

 

 

▐ 授权码生成规则

本文权限校验基于 Spring-security 进行改造拓展

 

建议没有阅读过的朋友有机会可阅读下源码

https://spring.io/projects/spring-security#overview

 

对于 AuthToken 的定义我们一般定义

 

  • principal    验证主体

被验证主体的身份。在带有用户名和密码的身份验证请求的情况下，这将是用户名。调用者应为身份验证请求填充主体。

AuthenticationManager 实现通常会返回一个包含更丰富信息的身份验证作为应用程序使用的主体。许多身份验证提供程序将创建一个 UserDetails 对象作为主体

 

  • credentials  验证凭证

证明主体正确的凭据。这通常是一个密码，但可以是与 AuthenticationManager 相关的任何内容。呼叫者应填充凭据。

 

  • details        回话详情

存储有关身份验证请求的其他详细信息。这些可能是 IP 地址、证书序列号等。

 

  • authenticated  是否已认证

用于指示 AbstractSecurityInterceptor 是否应向 AuthenticationManager 提供身份验证令牌。通常， AuthenticationManager （或更常见的是，其 AuthenticationProvider 之一）将在成功身份验证后返回一个不可变的身份验证令牌，在这种情况下，该令牌可以安全地返回 true 给此方法。返回 true 将提高性能，因为不再需要为每个请求调用 AuthenticationManager 。

出于安全原因，这个接口的实现应该非常小心地从这个方法返回 true ，除非它们是不可变的，或者有某种方法确保属性自最初创建以来没有被更改

对内容进行加密，先前提到过几种常用的加密方式，对内容进行暴力加密解密也行。

但是这里要强调的是加密内容以及哪些必要参数

  • 用户 SessionID：SessionID 是必须的，颁发授权码授权的用户对象是谁；当然这里用 UserID 也行，但是要追加失效属性(过期时间)。

  • 授权接口列表：颁发访问授权码时候需要明确，授权码能访问哪些指定接口，而不能对所有接口全部开放。

  • 模块标识：颁发访问授权码时候最好明确是那个模块的业务，如何授权接口中包含模块标识二级路径这里就可以忽略了。

  • 业务标识：这里主要是针对特定场景下的业务标识。

 

 

 
public class MechanismAuthTokenUtil 
    private static final byte[] key = new byte[]-122, 47, -49, -55, -14, -99, -51, -69, -2, 124, -80, 45, 27, 76, -17, 92;

      private static AES aes;

      private static AES getAes() 
        if (aes == null) 
          aes = SecureUtil.aes(key);
        
        return aes;
      

      private static final String separator = ";";
      private static final String entitySeparator = "#";
      private static final String authSeparator = "\\\\|";
      private static final String authDelimiter = "|";
      
      ....
      
      /**
       * 生成授权码
       */
      public static String encode(String moduleKey, String primaryKey, String auth) 
        return encode(
            SessionUtil.getSessionId(), 
            moduleKey, 
            primaryKey, 
            auth);
      

      /**
       * 生成授权码
       */
      public static String encode(String sessionId, String moduleKey, String primaryKey, String auth) 
        return getAes().encryptBase64(sessionId + separator
            + moduleKey + entitySeparator
            + primaryKey + separator
            + auth);
      
      
      ....

 

 
 

三、解析授权码

解析授权码就是将密文解密的过程，一帮通过对称加密或者其他方式进行处理

 

  
/**
 * 解析授权码
 *
 * @param token 授权码
 * @return MechanismAuth
 */
public static MechanismAuth decode(String token) 
  try 
    return getMechanismAuth(token, getAes().decryptStr(token));
   catch (Exception e) 
    log.error("token(" + token + ")AES解密失败", e);
    return null;
  


private static MechanismAuth getMechanismAuth(String token, String decryptStr) 
  try 
    final String[] split = decryptStr.split(separator);
    final String[] entitySplit = split[1].split(entitySeparator);
    return new MechanismAuth(split[0], entitySplit[0], entitySplit[1], split[2]);
   catch (Exception e) 
    log.error("token(" + token + ")格式不正确", e);
    return null;
  

 

得到 AuthToken 定义内容

  • principal    验证主体

  • credentials  验证凭证

  • details        回话详情

  • authenticated  是否已认证

得到 AuthToken 在确定授权信息基本定义、明文组成规则、加密方式、解密方式后。还有知道系统在什么时候拦截较为合适。

 

四、授权拦截

对于 Web 服务拦截，如果基于 Spring-security 进行改造拓展,OncePerRequestFilter 那就是常驻贵宾了。先前在针对服务认证的时候有也有提及到过。

 

就不做过多说明实现拦截方法

▐ 官方注释上解释

OncePerRequestFilter 过滤器基类，旨在保证在任何 servlet 容器上每个请求分派一次执行。它提供了一个带有 HttpServletRequest 和 HttpServletResponse 参数的 doFilterInternal 方法。

 

从 Servlet 3.0 开始，过滤器可以作为发生在单独线程中的 REQUEST 或 ASYNC 调度的一部分被调用。可以在 web.xml 中配置过滤器是否应该参与异步调度。但是，在某些情况下，servlet 容器会采用不同的默认配置。因此，子类可以覆盖方法 shouldNotFilterAsyncDispatch()以静态声明它们是否确实应该在两种类型的调度期间被调用一次，以便提供线程初始化、日志记录、安全性等。这种机制补充而不是取代在 web.xml 使用调度程序类型配置过滤器的需要。

 

子类可以使用 isAsyncDispatch(HttpServletRequest)来确定过滤器何时作为异步调度的一部分被调用，并使用 isAsyncStarted(HttpServletRequest)来确定请求何时处于异步模式，因此当前调度不会是最后一个对于给定的请求。

 

另一种也出现在它自己的线程中的调度类型是 ERROR 。如果子类希望静态声明是否应该在错误调度期间调用一次，它们可以覆盖 shouldNotFilterErrorDispatch() 。

getAlreadyFilteredAttributeName 方法确定如何识别请求已被过滤。默认实现基于具体过滤器实例的配置名称

 

 

以上是关于微服务架构 | 如何让接口权限继续继承下去？的主要内容，如果未能解决你的问题，请参考以下文章

微服务架构 | 如何让接口权限继续继承下去？

从0开始的微服务架构：如何快速体验微服务架构？

从 0 开始的微服务架构：如何保障微服务架构下的数据一致性

从 0 开始的微服务架构：代码给你，看如何用Docker支撑微服务

spring cloud微服务架构中使用自定义注解实现简单的权限控制与权限开关

spring cloud微服务架构中使用自定义注解实现简单的权限控制与权限开关