yhzhu的随手记
0%

为什么企业 IAM 在联合登录之外还需要本地密码认证

发表于 分类于
探讨企业 IAM 架构中同时保留联合登录与本地密码认证的设计考量，分析容灾场景、安全成本分布与认证路径收敛的工程实践。

在上一篇《基于 OAuth2/OIDC 的企业级统一身份治理架构实践》中，我们展示了身份映射表中同时存在联合身份（OIDC_SUB）和本地身份（EMAIL_PWD）的设计。有读者提出一个问题：既然认证已经委托给上游 IdP，为什么还要自建用户名密码登录？这是否会引入额外的安全成本？

这个问题涉及认证架构中一个常被忽视的维度——认证路径的韧性设计。本文将从容灾场景、安全成本分布和架构收敛三个角度展开分析。

一、身份映射表中的主备关系

回顾上篇文章中的身份映射结构：

1
2
3
4
5
6
┌──────────┬──────────────┬──────────────────┬──────────────────┐
│ user_id  │  identifier  │  identity_type   │      角色         │
├──────────┼──────────────┼──────────────────┼──────────────────┤
│   100    │ aaa111bbb... │ OIDC_SUB         │  主力联合身份     │
│   100    │ zhang@co.com │ EMAIL_PWD        │  容灾/备用身份    │
└──────────┴──────────────┴──────────────────┴──────────────────┘

同一个用户绑定两种身份标识，它们在架构中的定位并非并列，而是主备关系：

  • OIDC_SUB：主力联合身份，承载日常 99% 的认证流量
  • EMAIL_PWD：容灾备用身份，在主力路径不可用时提供替代入口

这种设计的核心思路是将认证路径与最终身份标识解耦——无论通过哪条路径进入，下游系统看到的始终是统一的 uid。

二、上游 IdP 的可用性边界

2.1 外部服务的故障现实

任何外部 SaaS 服务都存在不可用的可能性。企业级身份提供商（Azure AD、Google Workspace、Okta 等）历史上发生过多次全球性服务中断：

  • 2023 年 7 月：Azure AD/Entra ID 大规模中断，影响 Microsoft 365、Teams、Power Platform 等全部依赖其认证的服务
  • 2024 年 1 月：网络路由变更导致的全球性认证中断

即使 SLA 达到 99.99%，年度计划外不可用时间仍有约 52 分钟。故障往往集中出现在工作日的业务高峰期。

2.2 完全依赖联合登录的风险链路

当 IAM 系统 100% 依赖上游 IdP 时，故障传播路径如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
上游 IdP 服务中断
    │
    ▼
所有依赖联合登录的内部系统无法认证
    │
    ▼
运维团队需要登录管理后台进行应急处理
    │
    ▼
管理后台同样依赖上游 IdP 认证
    │
    ▼
运维人员无法进入系统执行恢复操作

这个场景与数据中心需要带外管理（Out-of-Band Management）的逻辑一致——当主网络通道失效时，需要一条完全不依赖主干网络的独立通道来恢复系统。本地密码认证在 IAM 架构中承担的就是这个角色。

三、其他需要本地认证的场景

3.1 IdP 供应商迁移

企业在生命周期中可能经历身份提供商的切换：从 Okta 迁移到 Entra ID、从 Entra ID 迁移到 Google Workspace、从一个 OIDC Provider 切换到另一个等。迁移过渡期的状态通常为：

1
2
3
4
旧 IdP —— 正在停用，部分用户已迁出
新 IdP —— 正在启用，部分用户尚未迁入

过渡期内，两边的联合身份都可能存在不确定性

本地凭证在此阶段提供稳定的认证手段。

3.2 系统初始部署

IAM 系统自身就是认证基础设施。在系统初始部署阶段，上游 IdP 的集成尚未完成配置，首个超级管理员需要一个不依赖任何外部服务的入口来完成系统初始化。这是系统的自举（bootstrap）问题。

3.3 邮箱域名变更与账号锁定

公司并购、品牌重塑导致的邮箱域名变更，或上游 IdP 智能锁定机制触发的账号冻结，都可能使联合身份暂时不可用。对于需要执行紧急操作的系统管理员，独立的本地凭证提供了一条不受上游状态影响的通道。

四、安全成本的实际分布

4.1 用户规模决定安全投入量级

读者担心的逻辑链条是：

1
2
自建密码登录 → 需要自行管理密码安全 → MFA、暴力破解防护、泄露检测……
→ 安全成本显著增加

这个推导的前提假设是本地密码登录与联合登录面向相同的用户规模。在实际架构中，两个认证路径面向的用户群体存在显著差异：

维度 联合登录（上游 IdP） 本地密码登录
用户规模 全员（数百至上千人） 超级管理员（个位数）
攻击面 所有可访问公司网络的人员 已知身份的内部管理员
所需安全深度 MFA + 条件访问 + 风险评估 + 泄露检测 密码复杂度 + BCrypt + 失败锁定 + HTTPS
安全投入承担方 上游 IdP 本地系统

4.2 安全面的收窄效应

引入联合登录后，安全成本的实际变化是：

1
2
3
4
5
6
引入前：
  全员密码安全 = 密码策略 + MFA + 暴力破解防护 + 泄露检测 + SSO

引入后：
  全员 → 安全成本转移至上游 IdP
  个位数管理员 → 本地承担有限范围的密码安全

安全面从全员收窄至少数管理员，整体安全投入是下降的。

4.3 本地密码登录的最小安全清单

面向个位数管理员的场景，最小必要安全措施如下：

措施 实现成本 说明
密码复杂度策略 低 长度、字符类型要求
BCrypt 加密存储 低 Spring Security 默认支持，strength=10
失败次数锁定 低 N 次失败后锁定 M 分钟
强制 HTTPS 零 网关层统一处理
登录审计日志 低 记录时间、IP、结果
权限即时撤销 低 permission_version 机制

对于 5 个已知身份的管理员，上述 6 项措施已足够。面向数百人的场景则需要更完整的策略体系——这正是将主力认证交给上游 IdP 的原因。

五、认证路径的最终收敛

架构设计的核心意图在于认证路径的收敛：

1
2
OIDC 联合登录 → auth_identity 匹配 OIDC_SUB  → user_id = 100 → JWT uid = 100
本地密码登录  → auth_identity 匹配 EMAIL_PWD → user_id = 100 → JWT uid = 100

两条路径、两种身份标识、同一个用户。下游业务系统看到的始终是统一的 uid，无需感知用户的认证入口。

graph LR
    A[OIDC 联合登录] --> C[auth_identity 匹配]
    B[本地密码登录] --> C
    C --> D[user_id = 100]
    D --> E[签发 JWT uid=100]
    E --> F[下游系统 A]
    E --> G[下游系统 B]
    E --> H[下游系统 C]

这种设计使认证入口的选择成为架构层面的韧性决策，而非下游系统需要处理的业务逻辑。

六、小结

关注点 架构考量
重复建设 联合登录与本地认证是主备关系，非功能重复
安全成本 安全面从全员收窄至个位数管理员，整体投入下降
上游可用性 任何外部服务都存在不可用场景，需要独立逃生通道
架构收敛 多认证路径最终统一至同一 uid，下游系统无感知

在统一身份治理架构中，本地密码认证作为容灾兜底机制存在，安全成本在可控范围内。将主力认证流量委托给上游 IdP，同时保留极小范围的本地认证能力，是认证架构韧性设计的工程取舍。