本文来源于阿里云社区电子书《阿里云产品四月刊》
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级（1）https://developer.aliyun.com/article/1554227
访问控制模型
基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）是访问控制体系中两种主要的方法。RocketMQ ACL 2.0 将这两种方法进行了融合，打造出了一套更加灵活和强大的访问控制系统。
RBAC 是基于角色的访问控制模型，通过角色进行权限的分配。RocketMQ ACL 2.0 将用户角色划分为超级用户（Super）和普通用户（Normal），超级用户具有最高级别的 权限，能够无需授权即可访问资源，这简化了集群初始化及日常运维过程中的权限依赖 问题。而普通用户在访问资源之前，需要被赋予相应的权限，适用于业务场景中，对资 源进行按需访问。
ABAC 是基于属性的访问控制模型，通过用户、资源、环境、操作等多维属性来表达访问控制策略。RocketMQ ACL 2.0 为普通用户提供了这种灵活的访问控制机制。帮助管理员根据业务需求、用户职责等因素，对资源进行更加精细的访问控制。
在安全体系中，认证和授权分别扮演着不同的角色，RocetMQ ACL 2.0 将认证和授权进行了模块分离。这可以确保两个组件各司其职，降低系统的复杂度。认证服务致力于 验证用户身份的合法性，而授权服务则专注于管理用户权限和访问控制。这样的划分不 仅可以让代码更易于管理、维护和扩展，也为用户提供了使用上的灵活性。根据需求， 用户可以选择单独启用认证或授权服务，也可以选择同时启用两者。
这使得 RocketMQ ACL 既可以满足简单场景的快速部署，也能够适应复杂环境下对安全性的严格要求。
认证（Authentication）
认证作为一种安全机制，旨在验证发起访问请求者的身份真实性。它用于确保只有那些 经过身份验证的合法用户或实体才能访问受保护的资源或执行特定的操作。简而言之， 认证就是在资源或服务被访问之前回答“你是谁？”这个问题。
RocketMQ ACL 2.0 版本维持了与 ACL 1.0 相同的认证机制，即基于 AK/SK 的认证方式。这种方式主要通过对称加密技术来核验客户端的身份，保证敏感的认证信息（如 密码）不会在网络上明文传输，从而提升了整体的认证安全性。
为了提升 RocketMQ 系统的访问控制和权限管理，ACL 2.0 针对主体模型做了以下改进和扩展：
- 统一主体模型的抽象：为了实现不同实体的访问控制和权限管理，设计了统一的主 体接口，允许系统中多个实例作为资源访问的主体。用户作为访问资源的主体之一， 按照该模型实现了主体的接口。这为未来新实体类型的权限适配提供了扩展能力。
- 角色分级与权限赋予：
- 超级用户：为了简化管理流程，超级用户被自动授予了全部权限，无需单独配 置，从而简化了系统的初始化和日常的运维管理工作。
- 普通用户：普通用户的权限则需要明确授权。ACL 2.0 提供了相关的权限管理工具，可以根据组织的政策和安全需求，为普通用户赋予合适的权限。
- 支持用户状态管理：为了应对可能出现的安全风险，比如用户密码泄露，ACL 2.0 提供了用户的启用与禁用功能。当发生安全事件，可以通过禁用用户状态，快速进行 止血，从而达到阻止非法访问的目的。
客户端流程：
- 客户端在构建 RPC 请求时，检查是否设置了用户名和密码，若未配置，则直接发送请求；
- 若已配置，则使用预设的加密算法对请求参数进行加密处理，并生成对应的数字签 名（Signature）。
- 在请求中附加用户名和 Signature，并将其发送至服务端以进行身份验证。
服务端流程：
- 服务端接收到请求后，首先检查是否开启认证，若未开启，则不校验直接通过；若 已开启了，则进入下一步。
- 服务端对请求进行认证相关的参数进行解析和组装，获取包括用户名和 Signature 等信息。
- 通过用户名在本地库中查询用户相关信息，用户不存在，则返回处理无；用户存在， 则进入下一步。
- 获取用户密码，采用相同的加密算法对请求进行加密生成 Signature，并和客户端传递的 Signature 进行比对，若两者一致，则认证成功，不一致，则认证失败。
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级（3）https://developer.aliyun.com/article/1554225
