完整的 IAM 体系 ASCII 架构图 + 各子系统关系解释 + 为何这样拆分的原因
下面结合你现有的 4 个系统（ums / passport / sso / permission），并加入为了生态化、开放化和审计所必须新增的模块，为你输出一套完整的 IAM 体系 ASCII 架构图 + 各子系统关系解释 + 为何这样拆分的原因。 图结构遵循企业级 IAM、零信任以及未来 AI RCA 扩展的最佳实践。
一、完整 IAM 体系 ASCII 架构图（结合你现有系统）
+----------------------------+
| Admin Console |
| (账号/应用/权限/审计管理) |
+-------------+--------------+
|
v
+-----------------------------------------------------------------------+
| Core IAM |
| |
| +------------------+ +------------------+ +-------------+ |
| | ums |<----->| passport |<----->| sso | |
| | (用户/组织中心) | | (认证因子/协议层) | | (会话/SSO) | |
| +------------------+ +------------------+ +-------------+ |
| | | | |
| | | | |
| v v v |
| +---------------------------------------------------------------+ |
| | permission | |
| | (权限模型/角色/策略/授权决策 PDP + PEP) | |
| +---------------------------------------------------------------+ |
+-----------------------------------------------------------------------+
| |
| |
v v
+----------------------+ +-------------------------------+
| Audit Service | | Application Registry |
| (统一审计/风控/UBA) | | (Client/App/Scope/Callback) |
+----------+-----------+ +---------------+--------------+
| |
v v
+----------------+ +-------------------------+
| RCA Platform | | Open API Gateway |
|(可选:根因分析) | | (外部 API 鉴权/限流/SDK)|
+----------------+ +-----------+-------------+
|
v
+------------------------------+
| External Developers |
| (开放接口/SDK/Token 使用) |
+------------------------------+
可以进一步引入：加密机 + 风控服务
二、各子系统的作用、依赖关系、以及为什么这样拆
下面逐层拆解。
1. 核心 IAM（你已有的 4 大系统）
1.1 ums（用户中心 / Identity Center）
- 是所有身份数据的唯一来源（SSOT）。
- 保存用户信息、密码（或凭据哈希）、组织架构等。
- permission、passport、sso 全部要依赖 ums 的人和组织数据。
为什么必须独立？
账号体系是最基础的“身份域”。任何修改跨多个系统都会炸。 统一用户中心 = 避免重复、保持一致性。
1.2 passport（认证中心 / AuthN Service）
- 负责认证协议：OIDC、OAuth2、密码登录、短信、扫码、MFA 等。
- ums 只存储用户信息，passport 才负责“如何验证用户是本人”。
与 ums 的关系
passport 认证用户 → 去 ums 校验账号是否存在、是否禁用、密码策略等。
为什么独立？
认证是高风险操作，需要专门模块隔离风险。
1.3 sso（单点登录 / 会话中心）
- 负责颁发 Session、管理 Cookie、处理 Logout、单点登出。
- passport 是“校验身份”，sso 是“管理会话生命周期”。
为什么独立？
这是企业级 IAM 的典型架构（Authing、Okta、Keycloak 都是这样）：
- Authentication（认证）与 Session（会话）职责分离
- 可支持 OAuth2 的多终端会话管理、统一注销
1.4 permission（权限中心 / AuthZ Service）
- 负责权限模型、角色、策略、资源、Action
- 对所有系统提供：权限决策 PDP + 资源访问 PEP（由各系统接入）
与上面三个的关系
- 认证（passport）成功 → 新建 session（sso） → 请求业务 → permission 进行鉴权。
- ums 的用户和组织数据 → permission 用于角色绑定、组织授权。
为什么独立？
权限管理复杂度高、变更频繁，必须抽象出来。
2. 新增模块（为了生态、审计、可运维性）
2.1 Application Registry（应用注册中心）
类似 Keycloak “client”，Authing “应用”、“AWS Cognito App Client”。
职责：
- 应用注册（client_id、secret、redirect_uri）
- Scope 管理（授权范围）
- API 权限绑定
- 接入第三方 IdP
为什么必须新建？
因为你要搞“对外开放接口 + SDK”，没有它会出现以下问题：
- 下游系统不知道如何接入 OAuth2 / OIDC
- 无法进行 client 级权限控制
- 无法做对外 API 调用安全
它是生态化的核心基础设施。
2.2 Audit Service（统一审计中心）
记录：
- 登录、登出、Token 刷新
- 权限变更、角色变更、策略变更
- 用户风险行为
- API 访问日志（非业务，而是 IAM 范围内的鉴权行为）
作用
- 统一存储所有安全域操作日志
- 提供未来 RCA（根因分析）、风险风暴分析基础
- 业务系统的日志与你的权限审计不是一个域
为什么从 permission / sso 拆出来？
因为：
- 日志要求不可篡改
- 必须统一格式
- 跨系统关联分析（登录 + 授权 + API 调用）
- 将来你的 AI RCA 靠它做用户异常行为分析（UBA）
2.3 Open API Gateway（开放 API 网关）
职责：
- Token 校验（JWT / Introspection）
- 签名认证（AK/SK）
- Rate Limit、IP 限制
- 流量治理
- 为对外生态统一入口
- 所有访问都可以打到 Audit 里
为什么不复用你已有的后端接口？
因为：
- 内部 API（Admin、业务）与开放 API 的安全级别不同
- 对外 API 需要严格限流和审计
- 需要独立的凭证机制（AK/SK）
- 需要统一的错误码、签名算法、契约规范
2.4 Admin Console（管理后台）
统一一个前端来管理：
- 用户、组织
- 应用注册
- 权限策略
- 审计日志
- Token 管理
- 第三方 IdP 配置
为什么独立？
UI 不应与权限、认证混在同一后端。 保持干净的职责边界。
3. 可选：RCA Platform（未来扩展）
你的背景是做监控/报警/日志/智能根因分析平台。 IAM Audit 对接 RCA 后，可实现：
- 异常登录 → 用户行为分析
- 权限风暴检测 → 自动归因
- 链路错误追踪（登录 → SSO → API 调用 → 失败）
三、为什么这样拆？
下面总结核心原因：
1）清晰的安全域边界
- 身份域（ums）
- 认证域（passport）
- 会话域（sso）
- 授权域（permission）
- 审计域（audit）
安全分层是各大 IAM 产品公共架构。
2）符合 OAuth2 / OIDC / SAML 的原生模型
例如：
- Authorization Server = passport + sso
- Identity Provider = ums
- Resource Server = permission（决策）
- Client = Application Registry
拆分后各模块映射清晰。
3）支持生态化扩展
未来你会对外暴露：
- 登录接入
- API Gateway
- SDK
- 权限策略
这是必须模块化的。
4）满足企业安全审计 / 合规要求
统一审计是硬性要求，否则：
- 无法追踪
- 无法满足风控
- 无法满足安全检查
- 无法满足你的 AIOps 平台能力构建
