做了几年企业安全，我发现一个规律：几乎所有"权限失控"事故，最后都能追溯到身份数据没有统一。
某市级民政局的场景很典型------11 个异构业务系统（社会救助、婚姻登记、殡葬服务、低保审核......），分别由 5 家不同厂商在不同年份交付，每套系统一个账号体系。一名科室人员上午要在 4 个系统之间切换，密码记不住就写在便签上；有人调岗半年，原部门的系统权限还在；等保测评时被问"能否提供全局用户清单"，管理员只能一个系统一个系统导 Excel。
这篇文章把统一身份认证平台从规划到落地的完整路径拆开讲，包括身份源怎么选、异构系统怎么接、账号生命周期怎么自动化、等保条款怎么对应。案例基于安当 ASP 统一身份认证服务平台的真实实施。
一、先想清楚：统一身份认证到底统一什么
很多项目一上来就问"支持什么协议"，其实顺序错了。统一身份认证平台要统一的是四样东西，协议只是第四层的实现手段：
| 统一层次 | 统一内容 | 不统一的后果 |
|---|---|---|
| 统一身份管理 | 一个人在企业内只有一个数字身份 ID | 张三在 A 系统是 zhangsan、B 系统是 zs001，审计无法关联 |
| 统一认证 | 登录入口收敛，一次认证全域通行 | 每个系统各自校验密码，弱口令面难以收口 |
| 统一授权 | 权限基于角色/部门下发，而非逐系统手配 | 调岗、离职权限回收靠人工，必然有遗漏 |
| 统一审计 | 所有认证、授权、访问事件汇聚到一处 | 安全事件无法溯源，等保直接扣分 |
安当把这套能力概括为 5A 统一身份能力（统一身份管理、统一认证、统一授权、统一审计、统一应用门户）。落到产品上，ASP 是一个集中式身份安全中台，对上通过 SAML 2.0 / OAuth 2.0 / OIDC 对接业务系统，对下通过 AD/LDAP/HR/钉钉/企微对接身份源，中间是 SSO 认证中心、MFA 多因子引擎、RBAC 权限引擎和审计日志。
一句话概括建设目标：把"每个系统各管各的账号"，改成"一个身份底座供给所有系统"。
二、第一步：确定唯一可信身份源（这一步做错，后面全白搭）
统一身份认证项目最容易翻车的地方，不是技术对接，而是没定清楚"谁说了算"。
企业里常见的候选身份源有三个：HR 系统、AD 域、各业务系统自建用户表。实施时必须明确优先级：
HR 系统（人员主数据：入职/转岗/离职）
↓ 每日增量同步
AD / LDAP（账号与组织架构）
↓ 实时/定时同步
ASP 统一身份平台（全局身份 ID + 角色映射）
↓ SAML/OIDC/表单代填
11 个业务系统（只消费身份，不再自建账号）推荐实践：以 HR 为人员事实源，AD/LDAP 为账号载体，ASP 为身份中枢。
ASP 的身份源管理模块支持这几种接入方式：
- LDAP：标准协议，适用于 OpenLDAP 及各类目录服务
- Windows AD：域账号无缝同步，组织架构树自动映射为 ASP 部门树
- HR 系统对接：通过 RESTful API 拉取人员异动数据
- 钉钉 / 企业微信 / 微信扫码：移动端登录入口，同时作为身份源绑定
- 手动创建 + 批量模板导入：适合无 HR 系统的中小组织
有个细节值得强调：ASP 支持用户身份源多绑定------同一个人可以把 AD 账号、钉钉账号、微信账号都关联到同一个全局身份，实现"一号通"。这解决了一个很实际的问题：领导习惯钉钉扫码，运维习惯 UKey，一线人员习惯账号密码，但审计日志里必须是同一个人。
同步策略上建议这样配置：
| 事件 | 触发动作 | 时效要求 |
|---|---|---|
| 入职 | HR 建档 → ASP 自动创建身份 → 按岗位模板授予角色 | T+1 日内 |
| 转岗 | 部门变更 → 原部门角色自动撤销 → 新部门角色下发 | T+1 日内 |
| 离职 | HR 标记离职 → ASP 即时禁用身份 → 所有应用会话失效 | 实时（这条必须实时） |
| 长期未登录 | 90 天未登录 → 自动标记休眠 → 通知管理员复核 | 定时任务 |
离职这条要单独强调：必须做到即时禁用。传统模式下，管理员要挨个系统删账号，11 个系统删完可能过了一周；接入 ASP 后，在平台上禁用身份，所有走 SSO 的应用下一次令牌校验就会失败，会话立即中断。
三、第二步：11 个异构系统怎么接（分三类处理）
真实项目里的业务系统不可能都支持标准协议。实施时我习惯先做一次"接入能力盘点"，把系统分成三类，分别用不同策略：
第一类：支持标准协议的系统（约占 40%）
这类最省事。新建系统、主流 SaaS、开源系统基本都在此列。ASP 侧创建应用，配置 Client ID / 回调地址 / 协议类型即可。
以 OIDC 授权码模式为例，业务系统侧的对接大致是这样：
http
# 1. 用户访问业务系统，未登录 → 重定向到 ASP 授权端点
GET /oauth2/authorize
?client_id=welfare-system-01
&response_type=code
&scope=openid profile
&redirect_uri=https://welfare.gov.local/callback
&state=xY7kP2
# 2. 用户在 ASP 完成认证（含 MFA），ASP 回调业务系统
GET https://welfare.gov.local/callback?code=SplxlOB&state=xY7kP2
# 3. 业务系统用 code 换 token（服务端到服务端）
POST /oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOB
&client_id=welfare-system-01
&client_secret=******
&redirect_uri=https://welfare.gov.local/callback
# 4. 拿到 id_token 后校验签名与 claims，建立本地会话政务领域用 SAML 2.0 的也很多，ASP 同样支持，配置 IdP 元数据 + 断言消费地址即可。
第二类：可改造但不支持现代协议的系统（约占 35%）
这类系统有源码、有厂商维护，但用的是自研登录逻辑。两种做法：
- API/SDK 集成：ASP 提供 RESTful API 和前端 JavaScript SDK（支持 Vue/React），改造量通常在 1-2 人日
- 隐藏式模式（无用户源应用）：业务系统本身不维护用户表，登录态完全由 ASP 下发
第三类：闭源老旧系统（约占 25%，也是最头疼的）
厂商跑路、源码丢失、C/S 架构------这类系统在政务和制造业里比例惊人。ASP 的处理方式是零改造旁路接入：
- B/S 老系统：浏览器插件 / 反向代理拦截登录页，向平台申请解密后的凭据，模拟输入完成登录。用户全程看不到真实密码，平台还能定期轮换目标系统的密码
- C/S 客户端：通过 SLA 安全登录代理接管终端登录入口，强制先过统一认证
- 共享账号系统：交给 SYP 密码管理器托管，授权到人、授权到时间段，明文永不暴露
这一类的价值在于把审计盲区补上------以前"运营部三个人共用一个后台账号"，现在每次代填都绑定真实操作人。
四、第三步：权限模型别做太复杂（RBAC 够用）
见过不少项目把 ABAC 那套搬进来，结果管理员根本不会用。统一身份认证平台的权限模型，建议就用 RBAC，把复杂度留给角色定义。
ASP 的 RBAC 结构是四层：
用户 → 角色 → 权限分组 → 资源/应用
↑
部门/用户组（支持权限继承）实操建议：
- 角色按岗位定义，不按人定义。"低保审核员"是角色，"张三"不是
- 善用部门继承。多层级树形部门架构下，上级部门的策略可以向下继承，避免逐人配置
- 权限分组做打包。把"社会救助系统的查询+录入+导出"打包成一个权限分组，分配时一步到位
- 多级管理员分权。超级管理员管平台，各业务条线设子管理员，只能管自己的应用和用户
政务和集团型企业还会用到多租户：ASP 支持创建多个相互独立的公司租户，数据完全隔离，适合"局机关 + 下属事业单位"这种架构。
五、第四步：认证强度按场景分级，不要一刀切
统一身份认证不等于所有场景都上最强认证。合理的做法是分级：
| 访问场景 | 认证强度 | 具体因子 |
|---|---|---|
| 内网办公网访问 OA | 单因素 | 账号密码 / 钉钉扫码 |
| 访问含个人信息的业务系统 | 双因素 | 密码 + OTP 动态口令 |
| 管理员登录后台 | 强双因素 | 密码 + UKey（国密 SM2 证书） |
| 互联网侧远程访问 | 强双因素 + 设备校验 | 密码 + FIDO2/生物特征 |
| 操作系统/服务器登录 | 强双因素 | SLA 代理 + UKey / 指纹 |
ASP 的 MFA 模块支持的因子比较全：FIDO2/WebAuthn（指纹、人脸、硬件密钥）、UKey（KeyId / 公钥 / 证书三种绑定方式）、OTP 动态口令（TOTP，兼容谷歌/微软认证器，支持国密 SM3）、安全软锁 ID、短信/邮件验证码。用户可以自助绑定、解绑、切换设备，减轻管理员负担。
民政局那个项目最终选的是"密码 + UKey"，原因很实际：工作人员年龄结构偏大，手机装 App 推广成本高，UKey 插上就能用，而且符合政务领域对硬件密钥的偏好。
六、等保 2.0 条款怎么对应
做统一身份认证项目，验收环节一定会被问合规。这里给一张对照表，直接拿去写方案：
| 等保 2.0 三级要求 | 平台对应能力 |
|---|---|
| 应对登录用户进行身份标识和鉴别，身份标识具有唯一性 | 全局唯一身份 ID，多身份源绑定至同一身份 |
| 应采用两种或两种以上组合的鉴别技术 | MFA：密码 + OTP/UKey/FIDO2/生物特征 |
| 应提供并启用登录失败处理功能 | 失败锁定策略、异常登录告警 |
| 应对分散在各个设备上的审计数据进行收集汇总和集中分析 | 管理员日志 + 用户行为日志 + 设备日志，支持 Syslog 外发 SIEM |
| 应实现特权用户的权限分离 | 多级管理员、RBAC 权限分组 |
| 应授予管理用户所需的最小权限 | 角色最小化 + 权限继承 + 定期复核 |
| 密码算法应符合国家密码管理规定 | 国密 SM2/SM3/SM4 全支持 |
引用的标准依据：GB/T 22239-2019《网络安全等级保护基本要求》、GB/T 39786-2021《信息安全技术 身份鉴别相关标准》，国密算法遵循 GM/T 0002/0003/0004。
七、落地效果与实施周期参考
民政局项目的最终数据：
- 单次登录时间从平均 3 分钟缩短到 10 秒（原来要在多个系统间反复输密码）
- 账号运维效率提升约 80%，权限分配错误率降为零
- 等保 2.0 "统一身份鉴别"与"集中访问控制"两项合规通过
- 11 个系统全部纳入统一审计，可按人、按系统、按时间检索登录行为
实施周期参考（来自多个项目的经验值）：
| 工作项 | 典型周期 |
|---|---|
| AD 域 / LDAP 集成 | 1-2 周 |
| 标准协议应用（SAML/OIDC）单个对接 | 1 天 |
| 老旧系统旁路代理接入 | 2-5 天/个 |
| VPN、堡垒机 RADIUS 对接 | < 3 天 |
| 整体项目（10+ 系统规模） | 6-10 周 |
平台侧的性能容量：最大注册用户 100 万+、最大应用对接数 100 万+、并发 2000 QPS、平均认证延迟 < 50ms、用户检索响应 < 0.5 秒。高可用采用 Keepalived 虚拟 IP 漂移 + PostgreSQL/Repmgr 主从复制，RTO < 30 秒、RPO ≈ 0。
八、常见问题
Q：已经有 AD 域了，还需要统一身份认证平台吗？
AD 解决的是 Windows 生态内的域账号管理，但它不解决三件事：非 Windows 应用的 SSO、多因素认证、跨系统的集中审计。实际项目里 AD 通常作为 ASP 的身份源之一保留，而不是被替换。
Q：老系统实在改不动怎么办？
用旁路代理或浏览器插件做表单代填，不动一行源码。这是目前性价比最高的方案，代价是要在客户端装轻量组件。
Q：统一身份平台会不会成为单点故障？
这是必须回答的问题。生产环境务必上双机热备或集群：Keepalived 做 VIP 漂移，PostgreSQL 用 Repmgr + Pgpool 做主从复制与读写分离，心跳检测自动故障转移，非抢占式策略保证切换平滑。另外 SLA 终端组件支持离线令牌，断网时终端仍可完成认证。
Q：项目要从哪个系统开始接？
建议从"用户量大 + 改造容易"的系统起步（通常是 OA 或门户），快速让员工感知到 SSO 的便利，为后续推广积累支持。核心业务系统放第二批，老旧系统放第三批。
写在最后
统一身份认证平台的价值，不在于技术多先进，而在于它把散落在几十个系统里的身份数据，收敛成了一份可管、可控、可审计的资产。
对安全团队来说，这意味着终于能回答"现在有多少活跃账号、谁访问了什么、离职的人权限清干净没有"这三个问题；对业务部门来说，是少记 10 个密码、少填 10 次登录框。
这两件事同时成立的时候，项目才算真正落地。
本文技术内容参考《安当 ASP 身份认证服务平台技术白皮书 V4.0》。安当技术专注身份安全与数据加密，产品通过公安部第三研究所与国家密码局商用密码检测，已服务 400+ 企业客户。