微服务和分布式系统中的授权解决方案

本文是 《精读 Mastering ABP Framework》 2.3 探索横切关注点 - 使用授权和权限系统 一节的扩充内容，重点探讨了授权在分布式和微服务系统中遇到的挑战，以及 ABP Framework 中采用的解决方案。

认证 & 授权

• 认证（Authentication）：确认用户身份
  
• 授权（Authorization）：授予用户访问资源的权限
  

关于认证和授权的基础内容，可参考：第7章 探索横切关注点 - 使用授权和权限系统 。

在微服务和分布式系统，对于权限，我们需要考虑的更多，比如：如何在一个微服务中设置权限，而在另一个微服务中检测权限，以及权限如何集中管理。
分布式系统中，认证和授权信息通常以 令牌（Token） 方式描述，所以先了解令牌内容的格式以及令牌如何存储。
访问令牌

访问令牌内容如下：

访问令牌内容由多个声明（Claim）组成，包含标准声明和自定义声明。
标准声明（claims）

• Sub: 用户Id
  
• Role: 用户角色
  
• Scope: 允许的范围
  

存储访问令牌

对于WEB应用程序，存储在浏览器本地存储（Local Storage），键为 access_token id_token 。

对于其他类型的应用程序，同样可以在获取到访问令牌之后，在本地存储。
授权类型 & 需求

• 基于声明的策略
  
• 开/关风格权限（通常是基于用户和角色）
  
  
  
  • 开关数据保存在权限数据库中
    
  
  
• 自定义策略
  
  
  
  • 检查权限数据库并直接应用自定义逻辑
    
  
  
• 基于资源的策略
  
  
  
  • 检查权限数据库并根据请求的资源应用自定义逻辑
    
  
  

基于资源的策略

基于资源的策略，用一句话来描述就是：用户或客户端（C）是否可以在资源（R）上执行操作（A） ?
举个例子：权限控制：当前用户是否可以编辑产品信息?
我们使用基于资源的策略，来实现以上权限控制：操作（A）对应编辑；资源（R）对应产品信息；用户（C）对应当前用户。
关于编辑可能存在的授权逻辑：

• 如果产品被锁定，不允许
  
• 如果产品是由当前用户创建的，则允许
  
• 如果用户有编辑产品的权限，则允许，该权限由管理员管理用户
  
• 如果用户所属的角色有编辑权限，则允许
  
• 只有当用户在产品所属的部门中工作时，才允许
  

基于资源的策略，可以很好地处理以上授权逻辑。
需求：授权组件

设计一个良好的授权系统，我们通常需要考虑的四个点：

• 策略实施点
  
• 策略决策点
  
• 策略信息点
  
• 策略管理点
  

策略实施点（PEP: Policy Enforcement Point），即在哪里实施授权？ 在API网关中？还是在当前服务中?
策略决策点（PDP: Policy Decision Point）即在哪里执行授权逻辑？。在当前的过程中?还是在专门的服务中?
策略信息点（PIP: Policy Information Point）即 从哪里以及如何获取执行授权逻辑的数据？ 直接访问数据库？还是按需收集？
策略管理点（PAP: Policy Administration Point）即直接访问数据库?按需收集？ 通常系统中提供统一的管理界面。
架构讨论

基于前面授权组件的四个点，我们需要做一些讨论，以及清楚其实现方式的利弊。
讨论1：外部授权服务

策略实施点（PEP）发生在微服务中，在微服务中调用授权服务（PDP），进行权限控制。

如何获取应用数据？

• 直接从服务数据库中读取?
  
• 在授权服务调用发送数据?
  
• 将数据预复制到授权服务的数据库中?
  

其他问题:

• 授权服务调用上的网络延迟。
  
• 授权服务成为瓶颈。
  

讨论2：在API网关检查

策略实施点（PEP）发生在网关中，在网关中调用授权服务（PDP），进行权限控制。

优点

• 将授权逻辑与微服务解耦
  
• 防止未经授权的请求调用微服务
  

缺点

• 需要在API中自定义处理逻辑，受限于网关实现选择的技术
  
• 需要将权限映射到HTTP，如：URL, HTTP 方法和 HTTP头。
  

讨论3：授权类库

将策略实施点、策略决策点、策略信息点的操作封装为通用的类库，在微服务中调用管理权限。

优点

• 将授权逻辑与微服务逻辑解耦
  
• 应用程序数据可用
  
• 可以自定义授权逻辑
  

缺点

• 如果使用不同技术开发的微服务，如：.NET 、Python、Java，则存在问题，不能跨开发语言。
  

综合以上三种方案的优缺点，采用授权类库的方式。
讨论4：如何保存权限数据？

方式一：每个微服务在自己的数据库中都有自己的权限表?

• 难以管理(加载和保存)权限
  
• 很难得到所有的权限
  
• 服务的责任太大
  

方式二：一个中央权限数据库?

• 所有服务都通过授权库直接连接到该数据库。
  

综合以上两种方式，采用中央权限数据库，实现策略信息点。
讨论5：如何检查和管理所有权限？

方式一：询问所有微服务的权限需求？
问题：服务发现、性能、服务上的负载太多，难以管理权限。
方式二：计算微服务中的所有权限并在中心位置预缓存?
管理和刷新缓存非常困难，任意的数据更改可能会影响许多用户的权限，缓存会太大。
方式三：在权限管理服务的中心位置计算权限?
非常适合开/关风格的权限，对微服务内部的依赖最小。
综合以上三种方式，采用在权限管理服务的中心位置计算权限，实现策略管理点（PAP）。
ABP 解决方案

基于以上的架构分析，我们来看一看在 ABP Framework 中的具体实现。
权限管理

定义权限

检测权限

授予权限

定义权限


定义权限相关参数：

• 权限名称
  
• 显示本地化权限名称
  
• 其他依赖：功能，全局功能
  
• 自定义数据
  

微服务中的权限管理

权限管理UI

管理UI数据来自，权限管理微服务；其他微服务中权限数据（权限定义、权限组、授权信息）保存到权限管理数据库中。

在权限管理微服务中和其他微服务一样使用 ABP 授权类库。
基于资源的授权

ABP 采用基于资源的授权策略

权限过滤

需要获取 资源(实体) 列表，根据业务规则、用户预设和权限进行筛选。

上图代码中，根据实体中的信息实施相应的业务规则，设置权限：

• OrganizationId 组织Id，允许组织
  
• CategoryId 类别Id，允许类别
  
• AssignedUserId 分配用户Id，允许分配用户可见
  
• CreatorUserId 创建用户Id，允许创建用户可见
  
• IsResolved 是否解决，在UI过滤
  

更新权限定义

关于服务启动

• 计算所有权限定义的哈希值
  
• 与分布式缓存中的哈希值进行比较
  
• 序列化和保存权限定义(仅更改/新增)
  
• 更新权限戳以通知其他服务
  
• 使用微服务名称作为缓存键前缀
  

获取权限定义

获取逻辑

• 如果是最新的，检查权限缓存戳并使用内存中的缓存。频率控制(30秒)。
  
• 如果不同，获取并反序列化权限定义。
  

在服务器启动时，预缓存权限定义。

用户界面：检测所有权限

获取当前用户的所有授予权限的列表！我们为什么需要它？用于控制显示或隐藏菜单项；用于控制显示或隐藏UI中的部分内容，如：按钮，标题，工具栏等；用于检查SPA的客户端权限。

管理：管理所有权限

将管理一个角色或用户的所有权限在同一个地方显示。

结论

微服务和分布式系统中的授权系统设计：

• 设计注意事项：策略实施点、策略决策点、策略信息点和策略管理点。
  
• 集中存储权限数据。
  
• 集中管理，采用开关风格权限。
  
• 总是要求微服务自定义和基于资源的权限。
  
• 依赖数据库查询进行基于权限的过滤。
  

本文已收录到《精读 Mastering ABP Framework》 第六部分：扩展。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！