🌐 Language: English Version | 中文版
1. 架构场景与背景分析
在多业务系统并行的企业环境（如 OA、CRM、项目管理、财务等），集中化的身份治理是解决数据孤岛的关键。常见挑战包括：
- 准入逻辑分散：各业务系统独立实现准入，策略变更导致多点重构。
- 身份标识不一：不同服务对同一用户的标识规则（Email、Subject ID）冲突。
- 属性管理重复：组织架构在多处副本，缺乏单一事实来源。
成熟的身份源（Upstream IdP）主要负责解决身份真实性断言。本架构基于标准 OAuth2/OIDC 协议构建了身份中继层（Identity Relay Layer），实现了跨系统的统一准入决策与身份画像汇聚。
2. 逻辑架构设计
架构核心原则：上游身份提供商 (Upstream IdP) 负责身份真实性，内部身份系统负责准入判定与属性分发。
2.1 架构全景图
graph TB
subgraph U["用户层"]
EU["企业员工"]
AD["系统管理员"]
end
subgraph A["外部身份源 (Upstream IdP)"]
IDP["OIDC Provider"]
end
subgraph I["身份治理层 (Internal IAM)"]
IAS["Identity Access Service (IAS) - 准入决策引擎 + 会话管理"]
IMA["Identity Management API (IMA) - 读写管理后台"]
IDS["Identity Data Service (IDS) - 身份画像查询 (只读)"]
ISJ["Identity Sync Job (ISJ) - 镜像数据同步"]
end
subgraph G["API 网关层"]
GW["API Gateway - 身份透传 + 统一鉴权"]
end
subgraph B["业务系统层"]
APP1["业务系统 A"]
APP2["业务系统 B"]
APP3["业务系统 C"]
end
EU -->|OIDC SSO| IDP
EU -.->|OIDC SSO| IAS
IDP -->|OIDC Federation| IAS
AD -->|Email/Password| IAS
IAS -->|签发内部标准 JWT| GW
GW -->|Header 注入 X-User-Id| APP1
GW -->|Header 注入| APP2
GW -->|Header 注入| APP3
APP1 -->|查询用户画像| IDS
APP2 -->|查询用户画像| IDS
APP3 -->|查询用户画像| IDS
IMA -.->|配置分发| IAS
ISJ -->|增量同步| IDP
2.2 交互流分析 (Identity Flows)
A. 联合登录流程 (OIDC Federation)
此流程实现了基于标准 OAuth2 协议的身份中继，支持任意标准 OIDC Provider 的无缝接入：
sequenceDiagram
participant Browser as 用户浏览器
participant GW as API Gateway
participant IAS as Identity Access Service (IAS)
participant IdP as Upstream IdP
Browser->>GW: 访问受限系统 URL
GW->>IAS: Forward-Auth (JWT 校验)
IAS-->>GW: 未认证 (302 Redirect)
GW-->>Browser: 302 → 进入登录页
Browser->>IAS: 选择 "企业账号登录"
IAS-->>Browser: 302 → 跳转至上游 IdP
Browser->>IdP: 提交身份断言 (MFA/SSO)
IdP-->>Browser: 回调 IAS (Authorization Code)
Browser->>IAS: /oauth2/callback?code=xxxx
IAS->>IdP: 用 Code 换取 Token & UserInfo
IAS->>IAS: 内部身份汇聚 (Ext ID → UID)
IAS->>IAS: 创建 Session (SID)
IAS-->>Browser: 签发内部 JWT (含 UID, SID) + 写 Auth Cookie
Browser->>GW: 带 JWT 重新访问
GW->>IAS: Forward-Auth 判定通过
GW->>Browser: 转发至下游业务系统
B. 透明鉴权与准入流 (Decision Engine)
网关层通过准入引擎执行实时的精细化管控：
sequenceDiagram
participant Browser as 用户浏览器
participant GW as API Gateway
participant IAS as Identity Access Service (IAS)
participant Backend as 业务系统
Browser->>GW: 带 JWT 访问业务 API
GW->>IAS: Forward-Auth 调用
IAS->>IAS: 1. JWT 签名校验
IAS->>IAS: 2. 权限版本校验 (Permission Consistency)
IAS->>IAS: 3. 活跃会话校验 (Check SID in Cache)
IAS->>IAS: 4. 应用级准入判定 (Access Level Check)
alt 准入成功
IAS-->>GW: 200 OK + Header (X-User-Id, X-Sid)
GW->>Backend: 映射身份上下文请求业务
Backend-->>Browser: 返回数据
else 准入拒绝
IAS-->>GW: 403 Forbidden
GW-->>Browser: 403 Forbidden
end
3. 关键设计决策 (Rationale)
3.1 准入控制与业务权限的「解耦边界」
- 准入控制（Access Control）：由身份系统决定该用户是否有权进入此应用。
- 功能权限（Feature Permission）：应用内部通过 IAM 提供的属性自行判定。
决策依据：在本架构设计中，身份系统作为 Attribute Provider（属性提供者），而让业务系统保持 Rule Definer（规则定义者） 的角色，以防止中央身份系统过度侵入业务细节。
3.2 选型思路：协议中立性
架构选择 Spring Authorization Server 构建 IAS 核心：
- 优势：其纯净的 OAuth2 实现支持将任何第三方 Identity Provider 抽象为「身份源」。
- 横向对比：相较于 Keycloak，它提供了更灵活的 API 级扩展，便于插入自定义的「准入决策链」。
3.3 无状态与有状态的平衡 (SID 设计)
为支持「即时撤回权限」和「全局注销」：
- 设计点：在 JWT 中嵌入 Session ID (SID)，由后端 Redis 集群维护。
- 决策依据：OAuth2 协议本身不包含会话失效语义，此处通过 SID 机制补充了实时会话注销能力，以此满足企业级的管理精度需求。
3.4 权限即时生效：版本一致性校验
为了实现变更的「分钟级响应」：
- 用户与权限的映射持有
permission_version。 - 网关准入时进行版本匹配校验。
- 一旦管理员修改准入策略，版本号递增，促使所有活跃 Token 即刻失效，从而触发重新鉴权逻辑。
4. 身份汇聚：UID 驱动的统一画像
架构通过「身份联合转换」将异构账户标识转换为全局唯一的 UID。
1 | ┌──────────────────────────────────────┐ |
设计的核心在于实现 IDP-Agnostic（身份源无关），确保上游账号的变更（如企业更名导致的 Email 域名变更）不会影响业务系统中的数据关联。
5. 协作边界规范
通过标准化协议明确身份治理系统与上游 IdP 的协作：
| 职责方 | 负责的核心能力 |
|---|---|
| 上游 IdP | 身份断言 (Assertion)、MFA/SSO、生命周期同步 (HR 系统集成) |
| 内部治理层 | 准入决策、会话一致性管理、企业画像补全、全局操作审计 |
6. 实践小结
本架构旨在建立一套协议中立、职责清晰的身份治理桥梁：
- 协议中立：基于标准协议，不绑定特定供应商，可对接任意 OIDC Provider。
- 治理一致：通过网关注入实现身份的全局可信分发。
- 管理可控：通过 SID 和版本机制，将无状态协议的灵活性与有状态管理的安全性结合。