统一身份认证设计方案版.pdfVIP

统一身份认证设计方案版

去年年初，我所在的集团信息中心接到了一项核心任务：

整合分散在20多个业务系统中的用户认证体系。当时集团

下属的财务、OA、生产管理、客户关系管理等系统各自独立，

员工登录每个系统都需要记不同的x密码，运维团队每天要

处理近百起“忘记密码”或“x锁定”的工单，更关键的是，

不同系统采用的认证方式五花八门——有的用静态密码，有

的用LDAP，甚至还有系统仍在使用短信x这种易被拦截的方

式。这种“各自为战”的状态不仅让用户体验极差，更埋下

了严重的安全隐患：曾有一次，某部门员工因在多个系统使

用相同弱密码，导致其中一个系统被撞库攻击，连带其他系

统x信息泄露。

正是在这样的背景下，我们团队开始着手推进“统一身份

认证”项目。项目启动会上，技术总监明确要求：“要做就

做彻底的方案，不仅要解决当前的x分散问题，还要为未来

5年的系统扩展、多端支持（PC、移动端、IoT设备）和安

全升级预留接口。了”也就是从那时起，即“统一身份认证

设计方案版”的框架在我们的讨论中逐渐清晰。

首先要解决的是“统一”的核心定义。我们梳理了集团所

有在用系统的认证需求，发现最基础的共性需求有三个：一

是用户只需一套x密码即可访问所有授权系统（单点登录，

SSO）；二是认证过程必须可审计，所有登录、退出、权限变

更操作都要留痕；三是支持多因素认证（MFA），根据系统敏

感等级动态调整认证强度。基于这些需求，我们明确了方案

的设计目标：构建一个集中管理、灵活扩展、安全可控的身

份认证平台，实现“一次认证，全网通行”了。

接下来是技术选型。当时市场上主流的认证协议有

OAuth2.0、SAML、OpenIDConnect，我们对比了各自的适用

场景：SAML在企业内部系统间交互更成熟，但对移动端支持

较弱；OAuth2.0更适合API级别的授权，适合微服务架构；

OpenIDConnect则是在OAuth2.0基础上增加了身份验证层，

更适合需要用户身份信息的场景。考虑到集团正在推进微服

务改造，且未来会有大量移动端应用接入，最终选择了以

OAuth2.0为基础，结合OpenIDConnect的技术路线。同时，

为了兼容旧有系统（比如仍在使用LDAP认证的生产管理系

统），我们设计了“认证适配器”模块，通过配置不同的适

配器，将旧系统的认证请求转发到统一平台处理，避免了对

旧系统的大规模改造。

核心模块的设计是方案的关键。我们将整个平台拆分为四

个部分：用户身份管理中心、认证引擎、授权服务、审计与

监控。用户身份管理中心负责集中存储用户基本信息、角色、

权限，这里需要特别处理的是“用户信息同步”问题——集

团HR系统每季度会更新员工信息（入职、离职、调岗），我

们通过定时任务+事件触发（HR系统调用同步接口）的方式，

确保身份中心的用户状态与HR系统实时一致。认证引擎是

处理登录请求的核心，支持密码、短信x、指纹识别、硬件

令牌等多种认证方式，且可以根据登录场景动态组合：比如

员工在集团内网登录OA系统，只需密码认证；但登录财务

系统时，无论内外网都必须启用密码+动态令牌的双因素认

证。授权服务则负责生成和管理访问令牌（我们选择了JWT

作为令牌格式，因为其自包含、可扩展的特性适合分布式系

统），并与各业务系统的API网关集成，确保只有携带有效

令牌的请求才能访问资源。审计与监控模块不仅记录每个认

证事件的时间、-、设备信息，还通过机器学习模型监测异

常登录行为（比如同一x短时间内从北京和上海同时登录），

一旦触发告警，系统会自动锁定x并通知安全团队。

在实施过程中，我们遇到了两个最棘手的问题。第一个是

旧系统的兼容性。集团有3个上线超过10年的系统，代码

老旧且文档缺失，直接对接统一认证平台的API几乎不可能。

我们的解决办法是开发“代理认证服务”：在旧系统服务器

上部署一个轻量级代理，当用户尝试登录时，代理拦截登录

请求，将用户名密码转发到统一平台验证，验证通过后再返

回给旧系统，模拟正常登录成功的响应。这种方式只需要在

旧系统服务器上安装代理，无需修改原有代码，上线后测试

了3个典型旧系统，成功率达到98%。第二个问题是用户习

惯的迁移。项目初期调研显示，60%的员工担心“统一密码

如果泄露，所有系统都会被攻破”啦，针对这一点，我们在

方案中强化了“密码策略”和“风险感知”功能：强制