您的位置 首页 java

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

原文链接:

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

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

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

一、背景


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

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

如下面场景

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

此时我们有 两种解决思路

  • 在原有接口中继续优化参数,将需要第二次请求的入参和返回参数依次追加到同一个接口中
  • 新开发一个接口继续走权限校验和第一个接口实现的步骤一样。

但这两种方案都合理么?


二、生成授权码


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

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

授权码生成规则

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

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

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

#overview

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

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

  • principal 验证主体

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

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

  • credentials 验证凭证

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

  • details 回话详情

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

  • authenticated 是否已认证

用于指示 Abstract SecurityInterceptor是否应向 Authentication Manager提供身份验证令牌。通常, 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 进行改造拓展,OncePer REQUEST Filter那就是常驻贵宾了。先前在针对 服务认证 的时候也有提及到过。

  • Spring Cloud 中如何保证各个微服务之间调用的安全性?
微服务架构 | 如何让接口权限继续继承下去?

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

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

▐ 官方注释上解释

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

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

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

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

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

文章来源:智云一二三科技

文章标题:微服务架构 | 如何让接口权限继续继承下去?

文章地址:https://www.zhihuclub.com/184582.shtml

关于作者: 智云科技

热门文章

网站地图