基于微服务API级权限的技术架构

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 一般而言,企业内部一套成熟的权限系统,都是基于角色(Role)的 访问控制方法(RBAC – Role Based Access Control),即权限 (Permission)与角色相关联,用户(User)通过成为适当角色的成员而得到这 些角色的权限,权限包含资源(或者与操作组合方式相结合),最终实现权限控制 的目的。

背景

权限系统是根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源。

一般而言,企业内部一套成熟的权限系统,都是基于角色(Role)的访问控制方法(RBAC – Role Based Access Control),即权限(Permission)与角色相关联,用户(User)通过成为适当角色的成员而得到这些角色的权限,权限包含资源(或者与操作组合方式相结合),最终实现权限控制的目的。

一言以蔽之,基于角色的访问控制方法的访问逻辑表达式为“Who对What(Which)进行How的操作”,它的由内到外的逻辑结构为权限->角色->用户,即一个角色对应绑定多个权限,一个用户对应绑定多个角色,这也是秦苍基础架构部对于公共权限服务实现的基本指导思想。

权限服务与基础架构部其他公共服务的关系图

一.API权限定义、入库和拦截

对于API权限,我们实行基于注解(Annotation)的扫描入库和拦截,不需要业务服务自行在界面上录入

1、权限定义

API权限以每个接口或者实现类中的方法作为权限资源,每个权限和微服务名(Service Name)挂钩。

我们通过在业务服务的API上添加注解的方式,进行权限定义。基础架构部会提供一个权限组件(Permission Component)Jar给业务服务部门,里面包含了自定义的注解,这样的实现方式,对业务服务的影响非常小,增加权限机制只是在代码层面加几个注解而已。具体使用方式如下

对于一个普通的接口类,我们可以这样定义:

1
2
3
4
5
6
7
8
@Group(name = "User Permission Group", label = "用户权限组", description = "用户权限组")
public interface UserService {
     @Permission(name = "Add User", label = "添加用户")
     boolean addUser(@UserId String userId, User user);
 
     @Permission(name = "Delete User", label = "删除用户", description = "删除用户")
     boolean deleteUser(@UserId String userId, User user);
}

对于通过Swagger方式暴露出去的API,我们可以这样定义:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Path("/user")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
@Api(value = "User resource operations")
@Group(name = "User Permission Group", label = "用户权限组", description = "用户权限组")
public interface UserService {
     @GET
     @Path("/addUser/{userId}")
     @Permission(name = "Add User", label = "添加用户")
     boolean addUser(@PathParam("userId") @UserId String userId, User user);
 
     @POST
     @Path("/deleteUser/{userId}")
     @Permission(name = "Delete User", label = "删除用户", description = "删除用户")
    boolean deleteUser(@PathParam("userId") @UserId String userId, User user);
}

在上述简短的代码中,我们可以发现有三个自定义的注解,@Group、@Permission和@UserId。

  • @Permission,即为每个API(接口方法)定义一个权限,要求有name(英文格式),label(中文格式)和description(权限描述)
    • @Group,即定义的权限归属哪个权限组,考虑到一个接口中包含很多个API,接口数目又比较多,那么我们可以为每个接口下的所有方法归为一个组。业务服务可自行定义权限组,也可以选择不定义,那么会归属到默认预定义的权限组中
  • l@UserId,即业务服务需要在他们的API上加入用户ID的参数,当AOP切面拦截做权限验证时候,用户ID是需要传入的必要参数

2、权限入库和拦截

当API权限定义好以后,我们在权限组件里面加入扫描权限入库和拦截的算法。采用Spring AutoProxy自动代理的框架来实现我们的扫描算法。

2.1 创建PermissionInterceptor.java继承org.aopalliance.intercept.MethodInterceptor,步骤如下

  • 实现Object invoke(MethodInvocation invocation)方法,获取注解值
  • 根据不同注解进行不同的切面拦截,实现对@Group,@Permission和@UserId三个注解的权限拦截逻辑

2.2 创建PermissionAutoProxy.java继承Spring的org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator类,步骤如下

  • 在构造方法里设置好Interceptor通用代理器(即实现了MethodInterceptor接口的拦截类PermissionInterceptor.java)
  • shouldProxyTargetClass用来决定是接口代理,还是类代理。在权限定义的时候,其实我们还支持把注解加在实现类上,而不仅仅在接口上,这样灵活运用注解放置的方式-
  • getAdvicesAndAdvisorsForBean是最核心的方法,用来决定哪个类、哪个方法上的注解要被扫描入库,也决定哪个类、哪个方法要被代理。如果我们做的更加通用一点,那么可以抽象出三个方法,供getAdvicesAndAdvisorsForBean调用
1
2
3
4
5
6
7
8
// 返回拦截类,拦截类必须实现MethodInterceptor接口,即PermissionInterceptor
protected abstract Class<? extends MethodInterceptor> getInterceptorClass();
 
// 返回接口或者类的方法名上的注解,如果接口或者类中方法名上存在该注解,即认为该接口或者类需要被代理
protected abstract Class<? extends Annotation> getMethodAnnotationClass();
 
// 扫描到接口或者类的方法名上的注解后,所要做的处理
protected abstract void methodAnnotationScanned(Class<?> targetClass);

2.3 创建PermissionScanListener.java实现Spring的org.springframework.context.ApplicationListener.ApplicationListener接口,步骤如下

  • 在onApplicationEvent(ContextRefreshedEvent event)方法里实现入库代码
  • 在微服务的Spring容器启动的时候,将自动触发权限数据入库的事件

    通过上述阐述,我们就实现了权限的扫描入库和拦截

二、API权限所对应的角色(Role)管理

角色是一组API权限的汇总,每个角色也将和微服务名挂钩。角色组的作用是为了汇总和管理众多的角色

角色管理需要人工在界面上进行操作,角色管理分为角色组增删改查,以及每个角色组下的角色增删改查

三、 API权限所属的角色和用户(User)的绑定

权限不能直接和用户绑定,必须通过角色作为中间桥梁进行关联。那么我们要实现

  • 角色与权限的绑定,即一个角色和多个权限的关联
  • 用户与角色的绑定,即一个用户和多个角色的关联

角色和权限的绑定页面

 

用户和角色的绑定页面 </center

 

四、权限系统验证方式

1、API接入的验证方式

通过远程RPC方式的调用

1.1 扫描接入Permission组件的API Resource

1
2
3
4
5
6
7
@Configuration
@ComponentScan(basePackages = { "com.omniprimeinc.service.myservice " })
@Import({ com.omniprimeinc.commonservice.permission.api.config.Config.class,
com.omniprimeinc.commonservice.permission.annotations.config.Config.class })
public class Config {
 
}

1.2 通过API Resource去调用RPC接口获取验证结果

1
2
3
4
5
6
7
8
9
@Path("/authorization")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
@Api(value = "Authorization resource operations")
public interface AuthorizationResource {
@GET
@Path("/authorize/{userId}/{permissionName}/{serviceName}")
Boolean authorize(@PathParam("userId") String userId, @PathParam("permissionName") String permissionName, @PathParam("serviceName") String serviceName);
}

2、Rest调用的验证方式

http://host:port/authorization/authorize/{userId}/{permissionName}/{serviceName}

通过User ID、Permission Name(权限名,映射于对应的方法名)、Service Name(应用名)来判断是否被授权,返回结果是true或者false

五、权限服务和用户服务的整合

用户服务即整合了Ldap系统的用户和桥接业务用户系统

权限服务接入用户服务后,可以在权限授权页面上选取相应的用户进行权限授权

六、权限服务的安全控制

未来规划,服务之间的调用增加如下机制

  • 黑/白IP名单机制。当A服务调用B服务的时候,B服务会实现维护一个黑/白IP列表,表示B服务只允许在某个IP网段的A服务才能有权限调用B服务
  • 服务间约定的SecretKey。当A服务调用B服务的时候,两个服务之间实现实现约定API访问密钥,此密钥不能轻易泄密。这样就规避了B服务被模拟Rest请求调用(例如通过PostMan调用)
  • 服务的API签名。当A服务调用B服务的时候,A服务需要获得正确的B服务API的签名,才有权限去调用

http://blog.springcloud.cn/sc/mfw-jq/

 

相关文章
|
2天前
|
人工智能 API
阿里云微服务引擎及 API 网关 2024 年 6 月产品动态
阿里云微服务引擎及 API 网关 2024 年 6 月产品动态
|
1天前
|
监控 负载均衡 API
探索微服务架构下的API网关设计
【7月更文挑战第19天】在云原生时代,微服务架构以其灵活性和可扩展性成为企业数字化转型的优选。本文将深入探讨API网关在微服务架构中的核心角色,包括其设计原则、关键功能以及面临的挑战。我们将通过实例分析API网关如何提升系统的可维护性、安全性和性能,并讨论如何在复杂环境中实现高效的API管理策略。
31 9
|
2天前
|
负载均衡 安全 API
探索微服务架构中的API网关模式
【7月更文挑战第18天】在微服务架构中,API网关不仅是流量的守门人,更是服务的协调者。本文将深入探讨API网关的核心作用、设计原则以及实现策略,揭示其在微服务生态系统中不可或缺的地位。通过案例分析,我们将一窥API网关如何优雅地处理服务发现、负载均衡、认证授权等关键任务,同时确保系统的弹性和安全性。
|
3天前
|
Kubernetes API 开发者
探索现代后端开发中的微服务架构
【7月更文挑战第17天】本文深入探讨了微服务架构在现代后端开发中的应用,分析了其设计原则、优势以及面临的挑战。通过具体实例,展示了如何有效实施微服务架构,并讨论了相关技术栈的选择。文章旨在为后端开发者提供微服务实施的指导和最佳实践。
|
4天前
|
运维 监控 API
探索微服务架构:从理论到实践
【7月更文挑战第16天】本文旨在深入探讨微服务架构的核心概念、设计原则以及在实际应用中所面临的挑战与解决策略。通过对微服务的定义和优势进行阐述,分析其在现代软件开发中的重要性,并结合具体案例,展示如何将微服务理念应用于实际项目中,以提升系统的可维护性、可扩展性和敏捷性。
26 6
|
4天前
|
消息中间件 负载均衡 网络协议
探索微服务架构中的服务通信模式
【7月更文挑战第16天】在微服务架构的海洋中,服务间的通信宛如细丝相连,维系着整个系统的协同与和谐。本文将深入探讨微服务之间如何通过同步与异步通信模式进行交互,并剖析这些模式背后的技术原理及其对系统性能和可扩展性的影响。我们将从理论到实践,一探究竟。
19 6
|
1天前
|
存储 设计模式 负载均衡
深入理解微服务架构中的API网关
在微服务架构的海洋中,API网关扮演着灯塔的角色,指引着服务的交互与集成。本文将探讨API网关的核心功能、设计考虑因素以及其在微服务生态系统中的重要性。通过具体案例分析,我们将揭示API网关如何优化服务发现、负载均衡和安全性等关键方面,并讨论其对系统性能的影响。
10 2
|
2天前
|
存储 设计模式 缓存
探索微服务架构下的缓存策略
【7月更文挑战第18天】在微服务架构的海洋中,缓存策略如同指南针,指引着系统性能的优化方向。本文将深入探讨微服务环境下缓存的有效应用,从缓存的基本概念出发,到微服务架构中缓存的特殊需求,再到实际案例分析,最后讨论缓存一致性与失效策略,旨在为开发者提供一套完整的缓存解决方案框架。
|
1天前
|
设计模式 监控 Java
探索微服务架构的弹性设计模式
【7月更文挑战第19天】在现代后端开发中,微服务架构因其灵活性、可扩展性而受到企业的青睐。本文将深入探讨微服务架构中的弹性设计模式,包括其定义、重要性以及如何通过技术手段实现服务的高可用性和容错性。我们将通过实例分析,展示如何在微服务系统中应用这些模式以提高系统的整体稳定性和响应能力。
|
3天前
|
消息中间件 运维 API
探索后端开发中的微服务架构实践
本文将深入探讨微服务架构在后端开发中的应用,包括其设计原则、优势与挑战。通过对具体案例的分析,我们将了解如何在实际项目中有效实施微服务,以及如何克服实施过程中的常见问题。文章旨在为后端开发人员提供一套微服务架构的实践指南,帮助他们构建更加灵活、可扩展的系统。
12 1

热门文章

最新文章