IAM 基础回顾：核心模型与微服务定位
在深入异步任务编排引擎的权限校验之前，必须重新夯实 IAM 的基础概念。本章从 IAM 核心模型出发，对比主流授权模型，并明确 IAM 在微服务架构中的位置，为后续引擎设计建立统一的语义基础。
2.1 IAM 核心模型（用户、角色、权限、资源）
IAM 系统的核心由四个基本实体构成，它们之间的关系构成了权限管理的基石：
| 实体 | 定义 | 示例 |
|---|---|---|
| 用户 (User) | 系统的操作主体，可以是人、服务账号或设备。 | user:zhangsan、service:data-pipeline |
| 角色 (Role) | 权限的逻辑集合，作为用户与权限之间的中间层。 | role:admin、role:readonly |
| 权限 (Permission) | 对资源执行特定操作的许可描述。 | permission:task:execute |
| 资源 (Resource) | 被保护的对象，可以是 API、数据、文件或服务。 | resource:task:123、resource:namespace:prod |
关键原则： 用户不直接关联权限，而是通过角色间接获得。这种解耦使得权限变更只需调整角色定义，无需逐个修改用户。
下图展示了 IAM 核心实体之间的典型关系：
2.2 RBAC 与 ABAC 模型对比
RBAC（基于角色的访问控制）和 ABAC（基于属性的访问控制）是两种主流的授权模型，它们在灵活性、复杂度和适用场景上存在显著差异。
| 维度 | RBAC（基于角色） | ABAC（基于属性） |
|---|---|---|
| 授权依据 | 用户所属的角色 | 用户、资源、环境的多维属性 |
| 粒度 | 粗粒度（角色级别） | 细粒度（属性级别） |
| 灵活性 | 低，角色变更需管理员操作 | 高，策略可动态组合 |
| 管理成本 | 低，角色数量有限 | 高，属性与策略数量庞大 |
| 适用场景 | 组织架构稳定、权限层级清晰 | 多租户、资源属性动态变化 |
| 典型实现 | Spring Security、Kubernetes RBAC | AWS IAM Policy、OAuth2 Scopes |
实践建议： 在 IAM 异步任务引擎中，推荐采用 RBAC 为主体 + ABAC 为补充 的混合模式。基础的任务执行权限通过角色控制，而针对特定任务实例的细粒度访问（如仅允许任务创建者查看日志）则通过 ABAC 属性策略实现。
下图对比了两种模型的决策流程：
2.3 IAM 在微服务中的位置
在微服务架构中，IAM 不再是一个独立的单体模块，而是作为基础设施层的一部分，以 身份认证与授权网关 的形式存在。其核心职责包括：
- 统一认证入口： 所有微服务请求首先经过 IAM 网关进行身份验证（如 JWT Token 校验）。
- 分布式授权决策： 将权限校验逻辑下沉到 IAM 服务，避免每个微服务重复实现。
- 策略集中管理： 通过 IAM 控制台统一管理用户、角色、权限策略，并实时同步到各服务。
- 审计与合规： 记录所有鉴权请求，为安全审计提供完整链路。
常见陷阱： 在微服务中，不要将 IAM 逻辑硬编码在每个服务的代码中。这会导致策略不一致、升级困难。正确的做法是将 IAM 作为独立服务部署，并通过 Sidecar 模式 或 API 网关 进行集成。
下图展示了 IAM 在典型微服务架构中的部署位置：
关键设计决策： 在异步任务编排引擎中，IAM 的权限校验需要同时支持 同步调用（如用户触发任务）和 异步回调（如任务完成后的状态更新）。这要求 IAM 服务提供无状态的 Token 校验接口，并支持基于上下文的属性传递。