基于ASP身份认证网关实现Web系统免代码改造的单点登录方案

摘要：在企业数字化转型过程中，遗留系统（如OA、HR、ERP）往往因技术陈旧、源码缺失或厂商失联，无法支持现代身份协议（如SAML、OIDC），导致单点登录（SSO）改造成本高昂甚至不可行。本文提出一种基于ASP身份认证网关 （Authentication Service Platform Gateway）的代理式SSO架构，通过反向代理+协议转换+会话注入技术，在不修改目标Web系统任何代码的前提下，实现统一身份认证与单点登录。文章详细拆解认证网关的工作原理、部署模式、协议兼容性、会话同步机制及安全加固策略，并结合金融、制造、政务等行业实践，说明如何在保障业务连续性的同时，满足等保2.0对"统一身份认证"的合规要求。

1. 引言：遗留系统的SSO困境

随着企业IT系统数量激增，员工需频繁在OA、HR、CRM、ERP等数十个系统间切换，平均每天输入密码5--10次。这不仅降低效率，更带来严重安全风险：

密码复用：为方便记忆，用户在多个系统使用相同密码；
凭证泄露：弱密码、钓鱼攻击导致账号被盗；
权限失控：离职员工账号未及时禁用，形成"幽灵账户"。

因此，单点登录（SSO）------用户一次登录即可访问所有授权系统------成为企业身份治理的核心需求。

然而，现实远比理想复杂：

新建系统：可集成SAML/OIDC，支持标准SSO；
遗留系统 （Legacy Systems）：
- 基于ASP.NET Web Forms、Struts、PHP等老旧框架；
- 无源码或厂商已倒闭；
- 认证逻辑硬编码在登录页，无法对接外部IdP；
- 甚至仍在使用Basic Auth或表单硬编码。

典型场景 ：某制造企业ERP系统为2008年定制开发，登录页为/login.asp，提交username和password字段，无API、无标准协议支持。

对这类系统进行SSO改造，传统方案面临三大难题：

代码改造难：需重写认证模块，成本高、周期长；
测试风险大：改动可能引发业务中断；
厂商依赖强：原开发商已失联，无人维护。

因此，企业亟需一种免代码、低侵入、高兼容的SSO方案。

2. ASP身份认证网关：SSO的"无感代理"

2.1 什么是ASP身份认证网关？

ASP（Authentication Service Platform）身份认证网关是一种部署在用户与Web应用之间的反向代理中间件，其核心能力包括：

协议转换：将SAML/OIDC等标准协议转换为目标系统的原生登录方式；
会话注入：在用户通过统一认证后，自动模拟登录目标系统；
凭证托管：安全存储目标系统的登录凭证（加密）；
访问控制：基于统一身份策略控制资源访问；
审计日志：记录用户访问行为，满足合规要求。

关键价值 ：对目标Web系统零改造，对用户无感登录。

2.2 与传统SSO方案对比

方案	是否需改代码	兼容性	实施周期	适用系统
SAML/OIDC集成	是	仅支持标准协议	2--8周	新建系统
同域Cookie共享	是	仅限同域名	1--2周	同源系统
代理式认证网关	否	任意Web系统	1--3天	遗留系统

结论：对于无法改造的遗留系统，认证网关是唯一可行路径。

3. 技术架构与工作原理

3.1 整体架构

复制代码

[用户浏览器]
     │
     ▼
[统一登录门户] ←─ 一次登录（账号+密码+2FA）
     │
     ▼ (重定向)
[ASP身份认证网关] ←─ 反向代理所有目标系统
     │
     ├─ 模拟登录 ERP（POST /login.asp）
     ├─ 注入会话 Cookie → [ERP系统]
     ├─ 模拟登录 OA（GET /sso?token=xxx）→ [OA系统]
     └─ ...

3.2 核心流程（以ERP系统为例）

用户访问 https://erp.company.com；
请求被DNS或Nginx转发至ASP认证网关；
网关检查用户是否已通过统一认证：
- 若未登录，重定向至统一登录门户；
- 若已登录，继续下一步；
网关从凭证库中取出该用户在ERP系统的密码（加密存储）；
网关自动构造POST请求 ，向ERP的/login.asp提交username和password；
ERP返回登录成功响应（含JSESSIONID等Cookie）；
网关将该Cookie透传给用户浏览器；
用户浏览器后续请求携带Cookie，ERP认为用户已登录。

全程用户无感知：URL不变，页面无跳转，体验如同直接登录。

4. 关键技术实现

4.1 凭证安全存储

加密存储：用户在各系统的密码使用KMS主密钥加密后存入数据库；
字段级加密 ：仅存储必要字段（如erp_password），不存用户名（可映射）；
权限隔离：网关进程以最小权限运行，数据库访问受ACL控制。

示例：

用户zhangsan在统一身份库中绑定：
json 复制代码
{
  "system": "ERP",
  "username": "zhangsan_erp",
  "password_enc": "AES256(SM4(...))"
}

4.2 登录脚本配置（无需编程）

网关通过可视化配置定义每个系统的登录逻辑：

系统	登录URL	用户名字段	密码字段	成功标识	失败标识
ERP	/login.asp	txtUser	txtPwd	"Welcome"	"Invalid"
OA	/sso/login	uid	pwd	302跳转	200含"error"

支持类型：

表单POST（最常见）；

URL参数GET（如?user=xxx&pass=yyy）；

Token交换（如调用内部API获取SessionID）。

4.3 会话同步与保持

Cookie透传 ：网关解析ERP返回的Set-Cookie，原样转发给浏览器；
会话续期：若检测到ERP会话过期（如返回登录页），自动重新模拟登录；
登出同步：用户在统一门户登出时，网关向所有系统发起登出请求（可选）。

4.4 安全加固

防重放攻击：每次模拟登录使用一次性上下文；
IP绑定：可选将ERP会话与用户源IP绑定；
操作审计：记录"谁在何时访问了哪个系统"，含源IP、设备指纹；
2FA集成：统一登录支持短信、OTP、USB Key等双因素认证。

5. 部署模式选择

5.1 集中式部署（推荐）

所有系统域名解析至认证网关；
网关集群部署，后端连接各应用服务器；
优点：统一管理，策略集中；
缺点：需调整DNS或反向代理。

DNS: erp.company.com → 10.10.1.100 (ASP网关)
Nginx: oa.company.com → 10.10.1.100

5.2 旁路式部署（无DNS变更）

仅对特定系统启用代理；
通过浏览器插件或PAC文件引导流量；
适用于无法修改DNS的场景；
缺点：用户体验略差（需安装插件）。

6. 合规性与审计要求

合规标准	要求	本方案实现方式
等保2.0三级	"应提供统一身份认证"	通过认证网关实现SSO
等保2.0三级	"应记录用户操作行为"	审计日志含访问时间、系统、IP
ISO 27001 A.9.4.1	"用户访问权限应定期审查"	统一身份库支持权限回收
GDPR Article 32	"适当技术措施保护数据访问"	凭证加密存储，防未授权访问

审计日志字段：

用户名、访问系统、时间、源IP、设备类型；

是否成功登录；

使用的第二因素类型（如TOTP）。

7. 某大型金融机构实践：200+遗留系统SSO整合

背景

该银行有200+内部系统，其中60%为2010年前开发的遗留系统，包括：

COBOL后端的信贷系统；
ASP.NET Web Forms的柜员系统；
PHP开发的内部论坛。

原每人平均管理15个账号，离职员工账号清理滞后，多次发生越权访问事件。

需求

实现全系统单点登录；
不改造遗留系统；
支持国密USB Key双因素认证；
满足银保监会《金融数据安全分级指南》。

方案实施

部署ASP认证网关集群：北京、上海双活；
统一身份库建设 ：
- 对接AD，同步员工账号；
- 为每个用户在各系统创建映射账号（如zhangsan_erp）；
- 初始密码由HR系统同步，后续由用户自助修改；
配置登录脚本 ：
- 信贷系统：POST /auth，字段user/pass；
- 柜员系统：GET /login?uid={username}&pwd={password}；
安全策略 ：
- 核心系统强制USB Key登录；
- 所有访问记录接入SIEM系统；
- 设置"异常时间登录"实时告警。

成果

SSO覆盖率达98%（仅3个系统因协议特殊未接入）；
账号清理效率提升10倍（统一禁用身份即全系统失效）；
一次性通过银保监会安全检查。

8. 自研 vs 商用ASP网关：如何选择？

维度	自研方案	商用ASP网关
开发成本	高（需实现协议解析、会话管理、安全审计）	低（开箱即用）
多系统兼容	有限（需逐个适配）	内置100+系统模板（SAP、Oracle、用友等）
凭据安全	需自行实现KMS集成	内置国密SM4加密，支持HSM
合规就绪	需额外开发审计模块	内置等保/GDPR模板
运维复杂度	高（高可用、灾备、升级）	低（厂商提供支持）

建议：若企业需快速上线、支持国密、降低长期运维风险，采用专业ASP网关是更高效的选择 。

安当ASP身份认证网关 正是面向此类场景的企业级SSO代理平台。其支持表单/GET/Token等多种登录方式，内置用友、金蝶、SAP、Oracle EBS等常见系统模板，并提供国密USB Key、FIDO2等双因素认证能力，已在银行、保险、制造、政务等领域落地。

典型应用：

某股份制银行实现200+遗留系统免改造SSO；

某车企研发中心统一访问Jenkins、GitLab、NAS等工具；

某省级政务云满足"统一身份认证"等保要求。

9. 未来演进：从SSO到零信任访问代理

随着零信任架构普及，认证网关将演进为应用访问代理（Application Access Proxy）：

设备信任评估：结合终端安全状态动态授权；
微隔离：按用户角色控制页面级访问（如仅看报表，不能导出）；
无密码化：全面转向FIDO2/生物识别，消除密码依赖；
云原生支持：在K8s中以Sidecar模式部署，保护微服务。

而这一切的基础，是一个灵活、安全、可扩展的身份代理平台。

10. 结语

单点登录不是炫技，而是企业身份治理的底线。面对海量遗留系统，与其陷入"改还是不改"的两难，不如选择一条免代码、快落地、高安全的技术路径。

ASP身份认证网关的价值，不仅在于技术实现，更在于让安全与业务和谐共存------既守住合规底线，又不打断业务连续性。选择合适的技术架构，让每一次系统访问，都成为一次安全、无缝的体验。

真正的用户体验，是感觉不到安全的存在；而真正的安全，是在无感中建立信任。