IDS Tenant Ops Docs main permissions-and-access-governance.md

权限与访问治理

本文档用于说明租户内角色分配、Claim / Scope 边界和应用访问开通与回收的治理口径，帮助团队把“谁能访问什么”拆清楚。

适用场景

  • 用户已有账号但无法访问应用或功能
  • 需要给用户、角色或组织开通应用访问权
  • 需要确认角色、Claim、Scope 的职责边界

负责角色

  • 租户管理员
  • 客户成功
  • 实施支持

核心边界

  • 角色 用于表达职责集合，适合做稳定授权
  • Claim 用于表达身份属性或细粒度声明，不应替代角色治理
  • Scope 用于表达应用或 API 请求授权范围，不应被当成后台岗位角色
  • 应用访问分配 用于控制主体是否能进入某个应用，与应用内功能权限是两个层面

推荐授权模型

建议按下面顺序治理授权：

  1. 先确认用户是否属于当前租户且状态正常
  2. 再确认用户是否能访问目标应用
  3. 再确认应用内角色或功能权限是否已配置
  4. 最后再看是否需要补充 Claim 或 Scope

这样可以避免把“应用访问没开通”和“应用内功能权限不足”混成同一个问题。

常见任务

  • 分析权限未生效属于应用访问、角色继承还是 Claim / Scope 配置问题
  • 给用户、角色或组织开通或回收应用访问权
  • 复核是否遵循最小权限原则

角色、Claim、Scope 的使用边界

角色

  • 适合表达岗位、职责或稳定权限集合
  • 优先用于后台运营能理解和复核的授权
  • 适合与应用访问分配、用户生命周期治理配合使用

Claim

  • 适合表达身份属性、标签、组织标识或更细粒度声明
  • 适合作为应用侧鉴权或展示逻辑的输入，不适合替代岗位角色
  • 使用前应明确 claim 的写入来源、变更责任人和覆盖规则

Scope

  • 适合表达 OAuth2 / OIDC 或 API 请求时的授权范围
  • 更像“请求范围”而不是“后台岗位职责”
  • 在租户运营排障中，通常只在接入或 token 行为异常时重点关注

应用访问分配的角色

  • 决定主体能否进入某个应用
  • 支持直接分配给用户，也支持通过角色或组织继承
  • 只解决“能否访问应用”，不直接解决“进入应用后能做什么”

常见误配场景

  • 给用户配了角色，但没有开通应用访问
  • 给应用开通了访问，但应用内角色或功能权限未配置
  • 用 Claim 承担角色职责，导致后续难以审计和批量回收
  • 把 Scope 当成人员授权模型使用，导致后台治理难以理解

排查顺序

  1. 确认用户和应用都属于当前租户且状态有效
  2. 确认应用访问分配是否存在、状态是否有效
  3. 确认角色授权是否存在以及是否实际继承到目标用户
  4. 确认 Claim 和 Scope 是否只是补充信息，而不是被误当成主授权手段
  5. 如仍不符合预期，再结合应用侧本地鉴权逻辑排查

相关 SOP

成功治理标准

  • 谁可以访问哪个应用是清晰且可追溯的
  • 应用访问分配、角色和功能权限的职责边界清晰
  • 变更后用户实际访问结果和预期一致
  • 过度授权和遗留权限可以被持续回收

延伸阅读

返回 租户运营配置文档