3. 授权服务边界定义
授权服务是 IAM 平台的核心决策引擎，负责判断“谁（主体）能否对什么（资源）执行什么操作（动作）”。明确授权服务的职责边界，是避免权限校验混乱、资源越权访问的关键设计步骤。本节从职责范围、资源控制边界、核心接口三个维度进行定义。
3.1 权限校验的职责范围
授权服务只负责权限判定，不负责身份认证、会话管理、资源元数据存储。其职责边界如下表所示：
| 职责归属 | 授权服务负责 | 授权服务不负责 |
|---|---|---|
| 身份确认 | 接收已认证的主体身份（用户ID、角色、属性） | 验证密码、签发 Token、管理 Session |
| 权限数据 | 读取策略、角色-权限映射、资源属性 | 存储用户表、资源实例详情、审计日志 |
| 决策逻辑 | 执行策略引擎（RBAC/ABAL/ABAC） | 业务规则编排、工作流审批 |
| 结果输出 | 返回 Permit / Deny / NotApplicable | 渲染 UI、触发业务回调 |
设计原则：授权服务应保持无状态（Stateless），所有决策依赖上下文参数和策略数据，不依赖本地缓存或会话状态，便于水平扩展。
3.2 资源访问控制的边界
资源访问控制边界定义了授权服务能够感知和判定的资源范围。通常划分为三层：
- 资源类型层：如“订单”、“文档”、“API 端点”。授权服务只识别资源类型标识（Type），不关心资源实例的具体字段。
- 资源实例层：通过资源 ID 或属性表达式（如
ownerId == userId）进行细粒度控制。授权服务接收资源属性，但不查询数据库获取属性。 - 环境上下文层：时间、IP、设备指纹等环境条件。授权服务仅做条件匹配，不采集环境数据。
以下 SVG 图展示了授权服务在资源访问控制中的边界位置：
3.3 授权服务的核心接口定义
授权服务对外暴露的接口应保持精简、语义明确。以下为标准化接口定义：
| 接口名称 | 请求参数 | 响应 | 说明 |
|---|---|---|---|
CheckPermission |
主体ID、资源类型、资源ID、动作、环境上下文 | Permit / Deny / NotApplicable | 单次权限校验，最常用接口 |
BatchCheck |
主体ID、资源类型、资源ID列表、动作 | 每个资源的判定结果列表 | 批量校验，减少网络开销 |
ListPermissions |
主体ID、资源类型、可选过滤条件 | 可执行的动作列表 | 用于前端菜单/按钮级权限展示 |
EvaluatePolicy |
策略ID、主体属性、资源属性、环境 | 策略匹配结果 + 生效规则详情 | 策略模拟与调试接口 |
接口设计要点：所有接口应使用 Protobuf 或 JSON Schema 定义严格的请求/响应结构；响应中必须包含
requestId 用于链路追踪；超时阈值建议设置为 200ms，避免阻塞上游服务。
3.4 授权服务内部处理流程
一次完整的权限校验请求在授权服务内部的流转路径如下：
- 请求解析层：校验请求参数完整性，提取主体身份、资源标识、动作、环境上下文。
- 策略匹配层：根据主体角色/属性，加载关联的策略集合（RBAC 角色策略 / ABAC 属性策略）。
- 策略评估层：按策略优先级逐条执行条件匹配，支持 Deny 优先或 Permit 优先模式。
- 结果聚合层：合并多条策略的评估结果，生成最终决策（Permit / Deny / NotApplicable）。
- 审计记录层：异步写入审计日志，记录决策上下文，用于事后追溯。
以下 SVG 图展示授权服务内部处理流程：
边界陷阱提醒：授权服务不应直接调用资源服务获取资源属性，这会导致循环依赖和性能瓶颈。正确的做法是：调用方在请求时携带必要的资源属性，授权服务仅做条件匹配。