一、身份认证中心 — 系统定位
身份认证中心是整个全域智能认证与门户平台的底座系统，承担"一次认证、全域通行"的核心职责。 它不是简单的登录页面，而是一个完整的 IAM（Identity & Access Management）平台， 向上支撑门户、移动端、第三方业务系统的认证需求，向下对接零信任网关、短信服务、各业务系统的用户数据库。
┌────────────────────────────────────┐
│ 调用方 / 消费端 │
│ 门户平台 │ 移动端 App │ 业务系统 │
└──────────┬─────────────────────────┘
│
┌──────────▼─────────────────────────┐
│ 身份认证中心 (IAM) │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ 认证引擎 │ │ 协议网关 │ │
│ │ 多因子鉴权│ │ CAS/OAuth/SAML │ │
│ └──────────┘ └──────────────────┘ │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ 用户管理 │ │ 策略引擎 │ │
│ │ 组织架构 │ │ 排他登录/设备绑定 │ │
│ └──────────┘ └──────────────────┘ │
└──────────┬─────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────────┐ ┌────────────┐
│ 达梦数据库│ │ ESB 总线/Redis│ │ 零信任网关 │
│ 业务/日志 │ │ 会话/缓存层 │ │ 深信服aTrust│
└──────────┘ └──────────────┘ └────────────┘
核心价值
- 统一入口：以员工工号为全系统唯一身份标识，消除多套系统多套账号
- 协议适配：7 大主流协议全覆盖，兼容新老系统认证需求
- 安全底座：多因子认证、设备绑定、零信任、审计日志构成安全防线
- 开放能力：多语言 SDK + 标准化 API，降低第三方系统接入成本
二、核心能力矩阵
| 能力域 | 子能力 | 需求要求 |
|---|---|---|
| 认证方式 | 基础认证 | 账号密码、短信验证码、APP 扫码 |
| 生物识别 | 指纹识别、人脸识别 | |
| 硬件/网络 | USBKey 证书认证、IP 认证 | |
| 协议支持 | 企业 SSO | CAS、SAML 2.0 |
| OAuth 生态 | OAuth 2.0、OpenID Connect | |
| 传统协议 | REST Protocol、Digest Authentication、Remote Address | |
| 策略控制 | 终端策略 | PC/移动端分别配置默认鉴权方式 |
| 会话策略 | 排他登录、强制手机绑定、设备绑定与数量限制 | |
| 安全策略 | 密码规则、错误锁定、验证码切换 | |
| 集成对接 | 应用集成 | 多语言 SDK（Android/iOS/JSP/JAVA/ASP/PHP/C/C#/VB） |
| 基础设施 | 零信任集成、短信模块、ESB 数据同步 |
三、多元化身份认证技术解析
3.1 认证方式矩阵
| 认证方式 | 技术原理 | 适用场景 | 安全等级 |
|---|---|---|---|
| 账号密码 | 用户输入预设凭证，服务端校验哈希 | PC 端基础登录、密码代填底层 | 中 |
| 短信验证码 | 服务端生成随机码通过短信网关下发，限时校验 | 移动端快捷登录、忘记密码重置 | 较高 |
| APP 扫码登录 | PC 端展示动态二维码 → App 扫码确认 → 服务端关联两端的 session | PC 端免密登录，安全且体验好 | 较高 |
| IP 认证 | 基于 Remote Address，信任内网 IP 段直接放行或降级验证 | 内网办公免登录、零信任内外网判断依据 | 低（需配合其他因子） |
| 指纹识别 | 移动端调用系统生物识别 API（Android BiometricPrompt / iOS LocalAuthentication） | 移动端快捷二次验证 | 较高 |
| 人脸识别 | 移动端摄像头采集 → 本地/云端活体检测 + 特征比对 | 高安全场景二次认证 | 较高 |
| USBKey 证书 | 基于 X.509 数字证书，私钥存储在硬件 USBKey 中，TLS 客户端证书认证 | 管理后台、高安全等级操作 | 高 |
3.2 终端自适应认证策略
需求要求"基于系统用户工作方式不同，分别配置 PC 端与移动端的默认鉴权方式"。这体现了一个核心设计理念： 认证方式不全局统一，而是按终端类型分别配置默认值。
设计意义
PC 端以键盘输入为主，默认推荐账号密码或 USBKey；移动端具备生物识别能力，默认推荐指纹/人脸。
系统管理员在后台为每种终端配置默认方式，用户可在允许范围内切换。
四、SSO 协议体系
4.1 协议对比
| 协议 | 类型 | 数据格式 | 典型场景 | 方向 |
|---|---|---|---|---|
| CAS | SSO 协议 | Ticket (ST/TGT) | Web 应用统一认证，企业/高校主流 | 中心化 |
| OAuth 2.0 | 授权框架 | JSON + JWT | API 授权、第三方应用接入、移动端 | 去中心化 |
| OpenID Connect | 身份认证层 | JWT (ID Token) | 基于 OAuth 2.0 的身份认证，现代 Web/Mobile App | 去中心化 |
| SAML 2.0 | SSO 协议 | XML | 企业级跨域 SSO，政企系统常用 | 联邦化 |
| REST Protocol | API 认证 | JSON | RESTful API 的 Token 认证 | API 级别 |
| Digest Authentication | HTTP 认证 | HTTP Header | 浏览器原生认证，替代 Basic Auth | 点对点 |
| Remote Address Auth | 网络层认证 | IP 地址 | 内网信任、零信任内外网判断 | 网络级别 |
4.2 CAS 协议核心流程
CAS（Central Authentication Service）是本项目最核心的协议——需对接 7 套已建系统 + 3 套待建系统：
① 用户访问业务系统
→
② 业务系统检查无本地 Session
→
③ 重定向到 CAS 认证中心
→
④ 用户在 CAS 中心完成认证
→
⑤ CAS 颁发 Service Ticket
→
⑥ 业务系统验证 ST 并建立 Session
五、零信任登录技术解析
5.1 什么是零信任
零信任（Zero Trust）的核心理念是 "永不信任，始终验证"（Never Trust, Always Verify）。 传统安全模型假设"内网即安全"，而零信任认为无论用户在内网还是外网，每一次访问请求都需要经过身份认证和授权。
5.2 深信服 aTrust 零信任体系
需求中明确要求集成深信服零信任（aTrust），实现用户无感登录并判断内外网逻辑。深信服 aTrust 的核心能力：
| 核心能力 | 说明 |
|---|---|
| 流量身份化 | 不再以网络位置（内网 IP）决定访问权限，所有访问主体（人/设备/应用）都需要身份标识 |
| 动态自适应访问控制 | 根据用户身份、设备状态、地理位置、行为基线等多维度进行持续信任评估，动态调整访问权限 |
| 网络隐身 | 业务系统不对外暴露端口和 IP，只有通过零信任认证的用户才能建立连接 |
| 终端环境检测 | 检测终端设备安全状态（是否越狱、杀毒软件是否运行等），作为信任评估因子 |
5.3 本项目零信任登录流程
需求中"内网无需调用零信任认证，外网需要通过零信任认证"的内外网判断流程：
① App 发起登录请求
→
② 判断网络环境（内网/外网）
→
③a 内网：直接走统一认证
→
③b 外网：先通过零信任认证
→
④ 统一身份认证
→
⑤ 颁发 Token，无感登录
5.4 零信任与 SSO 的关系
SSO 提供的是"一次登录、多系统通行"的便利，而零信任提供的是"持续验证、动态授权"的安全。 两者不是对立关系，而是互补关系：
- SSO 作为身份提供者（IdP），负责首次认证和令牌颁发
- 零信任网关作为策略执行点（PEP），在每次资源访问前验证令牌有效性和上下文安全
- 本项目中：深信服 aTrust 与统一认证中心对接，aTrust 可作为 CAS 的 Service Provider 消费认证
集成要点
深信服 aTrust 支持通过 CAS/OAuth2 协议与统一身份认证平台对接。App 端需集成 aTrust SDK，
实现"内外网自动判断 → 外网触发零信任认证 → 认证后无感访问业务系统"的完整流程。
六、密码代填方案
6.1 什么是密码代填
密码代填（Password Filling / Form-Fill SSO）是一种为不支持标准 SSO 协议的老旧系统 实现单点登录的技术手段。需求明确要求"以密码代填方式接入平台的老旧系统若干"。
原理：用户先通过统一认证中心登录 → 认证中心代管该用户的业务系统凭据 → 用户点击老旧系统时，认证中心自动导航到其登录页面 → 自动填充用户名和密码字段 → 自动提交表单。
6.2 代填登录流程
① 用户统一登录到 IAM
→
② 点击老旧系统入口
→
③ IAM 代管凭据注入代理页面
→
④ 代理页自动填充表单并提交
→
⑤ 用户无感进入老旧系统
6.3 安全风险与缓解
| 风险 | 缓解措施 |
|---|---|
| 凭据在 IAM 中明文或弱加密存储 | 使用 AES-256 加密存储，密钥与数据分库存放 |
| 老旧系统本身不支持 MFA | 在 IAM 侧增加前置 MFA 校验，代填后再过一层 |
| 老旧系统登录页面结构变更 | 代填模板支持配置化（字段选择器、提交 URL），便于维护 |
| 代填过程可能被中间人攻击 | 代理页面与老旧系统间强制 HTTPS 通信 |
定位
密码代填应作为过渡方案。长期应推动老旧系统改造为标准 CAS/OAuth2 接入。
需求中乙方已承诺承担第三方系统改造费用，这为推进老旧系统升级提供了预算保障。
七、CAS 对接架构
7.1 对接规模
- 7 套已建系统：安全生产综合管控平台、承包商系统、设备完整性系统、EAM 设备管理系统、实时数据库系统、生产调度指挥系统、综合管理平台
- 3 套待建系统：OA 办公系统、华锦邮箱、档案管理系统（建成后免费接入）
- 若干老旧系统：非 CAS 认证，以密码代填方式接入
7.2 统一身份标识
以员工工号作为全系统唯一身份标识。这意味着：
- CAS 认证中心的用户表以工号为主键或唯一标识
- 各业务系统需支持通过工号映射本地用户
- ESB 同步组织架构时，工号是关联字段
7.3 对接模式分类
| 对接模式 | 适用系统 | 实现方式 |
|---|---|---|
| CAS 原生对接 | 支持 CAS Client 的系统 | 业务系统集成 CAS Client SDK，验证 Service Ticket |
| SAML/OAuth2 桥接 | 仅支持 SAML 或 OAuth 的系统 | IAM 作为协议桥接器，将 CAS 认证转换为目标协议 |
| 密码代填 | 不支持标准协议的老旧系统 | 表单自动填充 + 代理转发 |
八、多语言 SDK 体系
需求要求第三方接入支持多种语言和平台，涵盖以下范围：
| SDK 类型 | 支持语言/平台 | 用途 |
|---|---|---|
| 移动端 SDK | Android SDK、iOS SDK | 移动端 App 集成认证、扫码登录、生物识别 |
| Java 系 | Java、JSP | Java Web 系统（Spring/Servlet）接入 CAS/OAuth |
| .NET 系 | ASP、C#、VB | .NET 业务系统接入统一认证 |
| PHP | PHP | PHP 业务系统接入 |
| C/C++ | C、C++ | 底层系统或嵌入式设备接入 |
| 标准化 API | RESTful API（语言无关） | 任意语言通过 HTTP 调用认证接口 |
实现建议
核心认证服务对外暴露标准 RESTful API，各语言 SDK 本质是对这些 API 的封装。
建议优先提供 Java、.NET、PHP 的官方 SDK（覆盖 90%+ 的业务系统），
C/C++ 等通过 REST API 直接调用，无需额外 SDK。
九、候选开源项目总览
基于需求中对协议支持（CAS + OAuth2 + SAML + 7 大协议）、多因子认证、多语言 SDK、国产化适配、10000+ 并发等要求， 筛选出以下 5 个主流开源 IAM 项目进行匹配度分析：
Keycloak
Red Hat 维护，市场占有率第一
Casdoor
Go 语言，Casbin 生态，轻量高效
MaxKey
国产 IAM，Apache-2.0，协议全覆盖
Apereo CAS
CAS 协议创始者，企业/高校标准
Apache Syncope
Apache 基金会，身份治理与生命周期
十、Keycloak 深度分析
| 维度 | 详情 |
|---|---|
| 维护方 | Red Hat → Linux Foundation（2024 年移交） |
| 技术栈 | Java / Quarkus |
| 协议支持 | OAuth 2.0、OIDC、SAML 2.0（CAS 需通过代理/插件） |
| 多因子认证 | WebAuthn、TOTP、OTP、短信、邮件 |
| 用户联合 | LDAP、Active Directory、Kerberos、Social Login |
| 扩展机制 | SPI（Service Provider Interface），高度可定制 |
| 社区规模 | 最大开源 IAM 社区，GitHub 22k+ Stars |
| 安可适配 | Java 跨平台，可运行于麒麟 OS + 达梦数据库（需 JDBC 适配） |
匹配度评估
| 需求项 | Keycloak 支持度 | 说明 |
|---|---|---|
| CAS 原生支持 | 部分 | 不原生支持 CAS Server，可作 CAS Client 或通过 SPI 扩展 |
| SAML 2.0 | ✅ 原生 | 原生支持 SAML IdP 和 SP |
| OAuth 2.0 / OIDC | ✅ 原生 | 完整支持 |
| 多因子认证 | ✅ 原生 | WebAuthn、TOTP、OTP 等 |
| 密码代填 | ❌ 不支持 | 需额外部署网关（如 F5 APM） |
| 多语言 SDK | 社区 | 官方不提供 SDK，社区有 Java/JS/Go 等 |
| 10000+ 并发 | 集群可达 | 单节点约 2000-3000 并发，需集群部署 |
| 移动端 SDK | 社区 | Android/iOS SDK 由社区维护 |
总结
Keycloak 是功能最完善的开源 IAM，但 CAS 非原生支持是其与本项目需求最大的 gap。
需要通过 SPI 扩展或部署 CAS 代理层（如 Apereo CAS 作为前置）来补齐。
十一、Casdoor 深度分析
| 维度 | 详情 |
|---|---|
| 维护方 | Casdoor 开源社区（Casbin 团队） |
| 技术栈 | Go（前端 React） |
| 协议支持 | OAuth 2.0、OIDC、SAML、CAS（原生）、LDAP、SCIM |
| 多因子认证 | TOTP、短信、邮件、WebAuthn |
| 权限引擎 | 内置 Casbin（支持 ACL、RBAC、ABAC） |
| 第三方登录 | 微信、钉钉、GitHub、Google、GitHub 等 30+ 平台 |
| 社区规模 | GitHub 10k+ Stars |
| 安可适配 | Go 编译为二进制，天然支持麒麟 OS；支持达梦数据库（需驱动适配） |
匹配度评估
| 需求项 | Casdoor 支持度 | 说明 |
|---|---|---|
| CAS 原生支持 | ✅ 原生 | 原生 CAS IdP，直接兼容需求中的 7 套系统对接 |
| SAML 2.0 | ✅ 原生 | 支持 SAML IdP |
| OAuth 2.0 / OIDC | ✅ 原生 | 完整支持 |
| 多因子认证 | ✅ 原生 | TOTP、短信、WebAuthn 等 |
| 密码代填 | ❌ 不支持 | 需自行开发代理填充模块 |
| 多语言 SDK | ✅ 官方 | 官方提供 Go、Java、Python、PHP、Node.js、C#、Swift 等 SDK |
| 10000+ 并发 | ✅ 单节点可达 | Go 高并发特性，单节点可支撑 10000+ 并发 |
| 移动端 SDK | 部分 | Swift SDK 支持 iOS，Android 可用 REST API 集成 |
| 设备绑定 | 可配置 | 通过自定义字段和策略实现 |
总结
Casdoor 是协议覆盖最全的开源 IAM——CAS、OAuth2、SAML 全部原生支持。
Go 语言在性能和安可适配上具有天然优势。社区 SDK 丰富度也最高。
主要短板：密码代填和设备绑定需二次开发。
十二、MaxKey 深度分析
| 维度 | 详情 |
|---|---|
| 维护方 | Dromara 开源社区（国产 IAM 第一品牌） |
| 技术栈 | Java / Spring Boot |
| 协议支持 | CAS（原生）、OAuth 2.x / OIDC、SAML 2.0、JWT、SCIM 2.0 |
| 多因子认证 | 图片验证码、短信验证码、TOTP/HOTP（Google/Microsoft Authenticator）、二次密码 |
| 第三方登录 | 微信、钉钉、新浪微博 |
| 社区规模 | Gitee + GitHub，Dromara 社区活跃 |
| 安可适配 | Java 跨平台，天然支持麒麟 OS + 达梦数据库 |
| 最新本 | 4.1.6（2025-02），持续迭代中 |
匹配度评估
| 需求项 | MaxKey 支持度 | 说明 |
|---|---|---|
| CAS 原生支持 | ✅ 原生 | 原生 CAS Server，直接兼容 |
| SAML 2.0 | ✅ 原生 | 支持 SAML IdP |
| OAuth 2.0 / OIDC | ✅ 原生 | 完整支持 |
| 多因子认证 | ✅ 原生 | 验证码、短信、TOTP 全覆盖 |
| 密码代填 | ❌ 不支持 | 需自行开发 |
| 多语言 SDK | Java 为主 | Java/CAS Client 完善，其他语言依赖 REST API |
| 10000+ 并发 | 集群可达 | Java/Spring Boot，单节点性能中等，需集群部署 |
| 国产化亲和度 | ✅ 国产 | 国产开源，中文文档完善，Dromara 社区国内活跃 |
| 排他登录/设备绑定 | ✅ 原生 | 支持会话管理、并发登录控制 |
总结
MaxKey 是国产化适配最友好的选择——CAS/SAML/OAuth 全部原生支持，中文文档完善，
国内社区活跃。排他登录、会话管理等需求功能原生具备。
短板同样在于密码代填和多语言 SDK 丰富度不如 Casdoor。
十三、Apereo CAS 深度分析
| 维度 | 详情 |
|---|---|
| 维护方 | Apereo 基金会（原耶鲁大学开发） |
| 技术栈 | Java / Spring Boot |
| 协议支持 | CAS（创始者）、SAML 2.0、OAuth 2.0、OIDC、REST |
| 多因子认证 | Duo、Google Authenticator、FIDO2/WebAuthn、Radius、短信 |
| 用户联合 | LDAP、Active Directory、JDBC、MongoDB、REST |
| 社区规模 | 企业/高校广泛使用，社区成熟 |
匹配度评估
| 需求项 | Apereo CAS 支持度 | 说明 |
|---|---|---|
| CAS 原生支持 | ✅ 创始者 | 本身就是 CAS 协议的参考实现 |
| SAML 2.0 / OAuth2 | ✅ 原生 | 完整支持 |
| 多因子认证 | ✅ 原生 | 自适应 MFA，支持多种因子 |
| 密码代填 | ❌ 不支持 | 需配合外部网关 |
| 用户管理 UI | 较弱 | 侧重认证，用户管理功能不如 Keycloak/Casdoor 完善 |
| 移动端 SDK | 无 | 无官方移动端 SDK |
| 门户集成 | 无 | 纯认证引擎，无门户/待办聚合能力 |
总结
Apereo CAS 是 CAS 协议的标准和参考实现，认证能力极强，但它是一个纯认证引擎，
缺乏用户管理 UI、门户集成、移动端 SDK 等项目所需的全栈能力。
更适合作为认证引擎与其他平台（如 Apache Syncope）组合使用。
十四、Apache Syncope 深度分析
| 维度 | 详情 |
|---|---|
| 维护方 | Apache 软件基金会 |
| 技术栈 | Java / Spring |
| 核心定位 | 身份治理与生命周期管理（非纯认证） |
| 协议支持 | 可对接 CAS/Keycloak 作为认证层 |
| 核心能力 | 身份生命周期（入职/转岗/离职）、Provisioning、多系统同步、合规审计 |
匹配度评估
定位差异
Apache Syncope 的核心优势是身份治理和生命周期管理，而非认证引擎。
它可以与 Keycloak 或 Apereo CAS 组合使用：Syncope 管身份数据和同步，Keycloak/CAS 管认证和 SSO。
对于本项目来说，如果选型 Keycloak，可以后续用 Syncope 补充用户生命周期管理能力。
十五、开源项目匹配度总对比
15.1 需求-项目匹配矩阵
| 需求维度（权重） | Keycloak | Casdoor | MaxKey | Apereo CAS |
|---|---|---|---|---|
| CAS 原生支持 必须 | 插件 | ✅ 原生 | ✅ 原生 | ✅ 创始者 |
| SAML 2.0 必须 | ✅ | ✅ | ✅ | ✅ |
| OAuth 2.0 / OIDC 必须 | ✅ | ✅ | ✅ | ✅ |
| 多因子认证 高 | ✅ 丰富 | ✅ | ✅ | ✅ 丰富 |
| 密码代填 高 | ❌ | ❌ | ❌ | ❌ |
| 多语言 SDK 高 | 社区 | ✅ 官方 8+ | Java 为主 | 无 |
| 移动端 SDK 中 | 社区 | Swift SDK | 无 | 无 |
| 排他登录/设备绑定 中 | ✅ | 可配置 | ✅ | 可配置 |
| 10000+ 并发 高 | 集群 | ✅ 单节点 | 集群 | 集群 |
| 安可适配 必须 | Java 可配 | ✅ Go 二进 | Java 可配 | Java 可配 |
| 国产化社区支持 中 | 国际 | 国际化 | ✅ 国产 | 国际 |
15.2 综合评分
| 项目 | 综合匹配度 | 优势 | 短板 |
|---|---|---|---|
| Casdoor | CAS/SAML/OAuth 全原生、Go 高性能、官方 SDK 丰富、安可适配最佳 | 密码代填/设备绑定需二开、项目相对年轻 | |
| MaxKey | CAS/SAML/OAuth 全原生、国产化最友好、排他登录原生、中文文档完善 | 密码代填需二开、多语言 SDK 较少、社区规模偏小 | |
| Keycloak | 社区最大、功能最全、生态最成熟、SPI 扩展能力强 | CAS 非原生、Java 资源消耗大、移动端 SDK 非官方 | |
| Apereo CAS | CAS 协议创始者、认证能力最强、自适应 MFA 成熟 | 纯认证引擎、无用户管理 UI、无移动端 SDK、无门户能力 |
十六、选型建议
16.1 推荐方案：Casdoor + 自研密码代填模块
综合匹配度最高的是 Casdoor，理由如下：
- 协议全覆盖：CAS、SAML、OAuth2 全部原生支持，直接满足 7 套系统 CAS 对接 + 多协议兼容需求
- Go 语言优势：单节点即可支撑 10000+ 并发，减少集群部署复杂度；编译为二进制文件，安可适配最简单
- SDK 生态：官方提供 8+ 语言 SDK，覆盖需求中要求的 Java、PHP、C# 等
- Casbin 权限引擎：内置 RBAC/ABAC，可直接支撑门户平台的差异化权限展示需求
- 轻量部署：单二进制文件 + 数据库即可运行，运维成本低
16.2 需自研的部分
| 自研模块 | 原因 | 工作量评估 |
|---|---|---|
| 密码代填引擎 | 所有候选项目均不原生支持 | 中（2-3 周） |
| 设备绑定/排他登录增强 | 需结合需求细化策略配置 | 小（1 周） |
| Android/鸿蒙 SDK | Casdoor 有 REST API，移动端封装 | 中（2-3 周） |
| 门户待办聚合 | 属于平台层功能，不在 IAM 范围内 | 大（独立模块） |
| 深信服零信任集成 | 需对接 aTrust SDK | 小（1 周） |
| 审计日志仪表盘 | Casdoor 有基础日志，需增强可视化 | 中（2 周） |
16.3 备选方案
- 备选 A：MaxKey——如果团队更看重国产化属性和中文社区支持，MaxKey 是最佳备选。协议覆盖同样完整，排他登录等需求功能原生具备。
- 备选 B：Keycloak + Apereo CAS 组合——Keycloak 作为 IAM 核心，Apereo CAS 作为前置 CAS 认证层。适合已有 Keycloak 使用经验的团队，但架构复杂度更高。
16.4 架构蓝图
┌──────────────────────────────────────────────────────────────────┐
│ 推荐架构 │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Casdoor（IAM 核心） │ │
│ │ ┌───────────┐ ┌───────────┐ ┌────────────────────────┐ │ │
│ │ │ CAS IdP │ │ SAML IdP │ │ OAuth 2.0 / OIDC │ │ │
│ │ └───────────┘ └───────────┘ └────────────────────────┘ │ │
│ │ ┌───────────┐ ┌───────────┐ ┌────────────────────────┐ │ │
│ │ │ MFA 引擎 │ │ Casbin │ │ 用户/组织管理 │ │ │
│ │ │ (TOTP/ │ │ (RBAC/ │ │ + ESB 同步 │ │ │
│ │ │ 短信/ │ │ ABAC) │ │ │ │ │
│ │ │ WebAuthn)│ └───────────┘ └────────────────────────┘ │ │
│ │ └───────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ ┌────────────────────┼────────────────────┐ │
│ │ │ │ │
│ ┌──────▼──────┐ ┌───────▼───────┐ ┌───────▼───────┐ │
│ │ 密码代填引擎 │ │ 深信服 aTrust │ │ 自研 SDK 层 │ │
│ │ (Form-Fill │ │ (零信任网关) │ │ Android/鸿蒙 │ │
│ │ 代理模块) │ │ │ │ Java/PHP/C# │ │
│ └─────────────┘ └───────────────┘ └───────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 数据层 │ │
│ │ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 达梦数据库 │ │ Redis 缓存 │ │ │
│ │ │ (业务 + 日志 │ │ (Session/ │ │ │
│ │ │ 分库分表) │ │ Token) │ │ │
│ │ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘