深入解析 simpliSSO:一个 12 模块的统一身份认证项目到底交付什么——从 Azure AD 联合到最后一套老旧 ERP

一家拥有几十套内部系统的企业,为什么需要统一的身份层?关于这个为什么,我们已经写过两篇:一篇讲工程团队中悄悄累积的身份债务,另一篇讲员工有 24 个密码,企业就有 24 个攻击面。8 月我们又补充了第三篇:进入通行密钥(Passkey)时代后,「注册」环节才是新的攻击面,而几乎所有的修补工作都落在身份提供商(IdP)一侧。

本文讲的是支撑这些论点的产品本身。simpliSSO 是 Simplico 构建并交付的统一身份门户:以 Authentik 作为身份提供商,与企业现有的 Microsoft 365 / Azure AD 租户联合,统一挡在所有内部应用之前。下面我们逐一说明交付范围里实际有什么、12 个模块如何组合、额外编写的代码做了什么,以及同样重要的——哪些按项目单独定范围,哪些明确不在范围内。

一、simpliSSO 面对的真实环境

产品页上的参考部署不是演示用的玩具,而是一个真实的形态:24 个服务、3 种协议、12 个功能模块、10 周上线。 而这 24 个服务并不都是现代 Web 应用,而是东南亚中型制造与分销企业(包括在泰国东部经济走廊设厂的中资企业)都很熟悉的组合:

• 新的内部 Web 工具(应收账龄、仓库报表、文档管控、IT 服务、审批流、项目报表)
• 支持 SAML2、但属性命名不标准的老旧 ERP——Infor M3
• WhatsApp Business、3CX IP 电话这类根本没有 SSO 概念的通信工具
• 京瓷打印机、标签打印机、仓库机器人系统这类只能走 LDAP、甚至完全无法认证的硬件

一个只能处理第一类的产品,大概只能覆盖一半系统,而把风险最高的另一半原封不动地留在那里。simpliSSO 从设计之初就是为这整套混合环境准备的。

二、三种协议、三层应用、一个身份提供商

架构是单一中枢。员工是谁,依然以 Azure AD 为准;谁能访问什么、由谁签发令牌,只由 Authentik 一处决定;每个应用用它实际支持的协议接入 Authentik。

flowchart TD
    STAFF["员工"] --> PORTAL["应用门户 磁贴入口"]
    PORTAL --> AK["Authentik 身份提供商"]
    AK --> AAD["Microsoft 365 与 Azure AD"]
    AAD --> AK
    AK --> POL["访问策略与阶梯式 MFA"]
    AK --> OIDC["OIDC 提供方"]
    AK --> SAML["SAML2 提供方"]
    AK --> LDAP["LDAP 前哨"]
    OIDC --> MAP["属性映射 写入 ERP 角色"]
    MAP --> T1["第一层 Web 应用"]
    SAML --> T1
    LDAP --> T3["第三层 打印机与老旧硬件"]
    PORTAL --> T2["第二层 WhatsApp 与 3CX 账号绑定"]

第一层——通过 OIDC 与 SAML2 接入的 Web 应用。 现代应用使用 OpenID Connect,拿到带签名的 JWT;老旧 ERP 使用 SAML2。Authentik 同时运行两种提供方,新的应收管理工具和用了十五年的 ERP 走的是同一扇门。

第二层——通过账号绑定接入的通信工具。 WhatsApp 和 3CX 无法使用 OIDC 令牌。因此在员工首次登录时,自定义的绑定环节会把每位员工的 WhatsApp 号码和 3CX 分机号绑定到其 Azure AD 身份,门户磁贴可直接跳转到对应的会话或已完成认证的电话客户端。

第三层——通过 LDAP 接入的硬件。 不支持 OIDC 或 SAML2 的打印机和标签设备,向 Authentik 部署的 LDAP 前哨进行认证;连 LDAP 都不支持的机器人系统,只通过门户深链接访问。

Azure AD 是默认的上游,但不是硬性依赖。Authentik 可以与 Google Workspace、Okta、通用 OIDC 或 SAML2 身份源联合;对于物理隔离或严格要求本地化部署的场景,还可以直接对接企业内部已有的 Active Directory 或 OpenLDAP,全程不经过云端。多个身份源还可以叠加在同一登录流程中,例如员工走 Microsoft 365,外包人员走 LDAP。

三、12 个模块

每个模块独立定范围、独立报价。其中 3 个为必选,其余可在签约前分期或删减,价格按比例调整。

模块	交付内容	标准项目中的定位
F-01 MS365 / Azure AD 联合	以 Azure 为上游 IdP,MFA 与条件访问策略直接透传	必选
F-02 Authentik 部署与加固	生产级 Docker Compose 栈:PostgreSQL、Redis、Nginx TLS、备份、管理后台、品牌定制	必选
F-03 应用注册	所有服务注册为 OIDC 或 SAML2 应用,基于用户组的访问策略,Blueprint YAML 配置即代码	必选
F-05 ERP 角色 JWT 声明	将公司代码、事业部与 ERP 角色写入令牌	可分期
F-06 阶梯式 MFA	访问指定敏感系统时再次要求 MFA	可分期
F-07 应用门户	FastAPI 接口,只展示用户有权访问的应用,带泰文/英文标签	可分期
F-08 WhatsApp 账号绑定	将员工 WhatsApp 号码绑定到目录账号	可分期
F-09 3CX 分机绑定	分机与账号对应,磁贴直接打开已认证的网页电话	可分期
F-10 Infor M3 SAML2 适配	把 Authentik 的 SAML2 输出转换为 M3 要求的非标准属性与 NameID	可分期
F-11 泰文界面	登录、MFA、错误提示与密码重置界面泰文化及品牌化	可分期
F-12 测试、QA 与验收	覆盖所有服务的端到端测试,包括令牌过期、MFA 失败、SAML 不匹配等场景	包含
F-13 文档与交接	架构图、管理员运维手册、入离职操作指南(泰文与英文),现场交接会议	包含

这张表有两点值得注意。第一,必选部分确实很小:Azure AD 联合、加固后的部署、应用注册。如果企业只想"把 Web 应用的登录统一起来",做到这里就可以停。第二,大部分可分期模块之所以存在,是因为真实环境里总有至少一套"不守规矩"的系统:属性名古怪的 ERP、没有 SSO 概念的电话系统、需要本地语言登录界面的一线员工。

四、定制 Python 层——以及为什么它归你所有

simpliSSO 中不属于现成 Authentik 的部分,是一层运行在 Authentik 内部的轻量 Python 代码,以表达式策略、属性映射和 Django 阶段的形式存在。没有需要额外运维的外部服务,而且所有这些 Python 代码在尾款支付后都成为客户的知识产权。

声明塑形(F-05)。 属性映射把 ERP 上下文——M3 的公司、事业部和角色,以及应收系统的访问级别——直接写入令牌。应用从令牌中读取角色,而不是自己维护一张权限表。这就是"用于登录的 SSO"和"用于授权的 SSO"的区别:员工在 Azure AD 中调岗后,下次登录时 ERP 角色在所有地方同步改变,不用等某个人想起来去改另一套系统。

阶梯式 MFA(F-06)。 一段约 20 行的表达式策略会检查目标应用是否在敏感系统名单上,以及上次 MFA 验证是否已超过 30 分钟;两者同时成立时,Authentik 会在签发高权限令牌之前再次要求验证。日常访问基本不会触发,而财务与 IT 管理类系统每次都会触发。

M3 适配(F-10)。 Infor M3 要求的属性名和 NameID 格式与标准 SAML2 断言不一致。我们不去改 ERP,而是在身份提供商一侧用自定义映射完成转换。这类模块之所以存在,正是因为已经有人在这上面耗掉过整整一周。

磁贴入口(F-07)。 FastAPI 接口负责渲染门户:只展示当前用户有权访问的应用,附带图标、泰文/英文标签和深链接。这是员工看到的第一个页面,而且它与访问控制使用同一套用户组策略生成——门户永远不会展示策略会拒绝的应用。

五、再接入一个应用,实际需要什么

新应用只需要四个环境变量:

OIDC_CLIENT_ID     = "your-app-client-id"
OIDC_CLIENT_SECRET = "your-app-client-secret"
SESSION_SECRET     = "random-256-bit-string"
OIDC_ISSUER_URL    = "https://sso.example.com/application/o/<app-slug>/"

每个 Authentik OIDC 提供方都会在 .well-known/openid-configuration 发布发现文档,应用从这一个 URL 就能获取所有端点、签名密钥和支持的作用域(包括自定义的 ERP 声明)。产品页提供了 FastAPI、Django、Express 和 PHP 的可运行示例,流程都一样:重定向到 Authentik、处理回调、从令牌读取用户组和角色。不需要自研认证代码,也不存在离职时容易漏关的应用级密码表。

六、10 周交付,按可验证的里程碑付款

分阶段推进,先证明基础可用,再开始定制工作:

flowchart TD
    W1["第1至2周 基础设施 F01 F02"] --> W3["第3至4周 核心 SSO F03"]
    W3 --> W5["第5周 ERP 声明 阶梯式 MFA M3 适配"]
    W5 --> W6["第6周 泰文界面与品牌"]
    W6 --> W7["第7至8周 门户 WhatsApp 与 3CX 绑定"]
    W7 --> W9["第9至10周 测试 验收 交接"]

付款与验收通过的交付物挂钩,而非日历日期:签约时 30%;Microsoft 365 联合上线且首批 5 个应用接入后 40%;全部服务上线并签署 UAT 后支付剩余 30%。上线后可选月度支持服务,分三档响应时效(下一工作日、4 个工作小时、2 个工作小时),提前 30 天书面通知即可取消,不设锁定期。

七、中文市场视角:等保2.0、《个人信息保护法》与数据不出境

等保2.0 的身份鉴别、访问控制与安全审计。 按照《网络安全等级保护基本要求》(GB/T 22239-2019),第三级系统要求对登录用户进行身份鉴别,并采用两种或两种以上组合的鉴别技术;同时要求按最小权限分配账户权限,并对重要用户行为进行审计。24 套系统各自管理账号、各自记日志时,要证明这些控制在每一套系统上都落实到位,几乎不可能。统一到 Authentik 之后,MFA 在身份层统一强制,权限由用户组集中下发,登录与访问事件在一处可查,测评时提供的是一套证据,而不是二十四套。

《个人信息保护法》的安全保护义务。 《个人信息保护法》第五十一条要求个人信息处理者采取相应的加密、去标识化等安全技术措施,并合理确定个人信息处理的操作权限。基于 Azure AD 用户组、通过令牌下发 ERP 角色(F-05)的做法,本身就是"合理确定操作权限"的落地方式;SCIM 在员工离职时即时吊销全部访问,则消除了最常见的幽灵账号问题。

数据不出境与本地化部署。 Authentik 部署在企业自己的服务器上,配置以 Blueprint YAML 的形式留在企业内部的版本库里。对于不便以境外云目录作为身份源的中国境内主体,可以直接以本地 Active Directory 或 OpenLDAP 作为上游,登录全程不经过境外云服务。这也让 simpliSSO 能够作为"智改数转"项目中身份底座的一部分,与 MES、ERP 等系统一起规划。

八、已交付功能、按项目配置、以及不在范围内的内容

身份领域是一个夸大其词会造成真实损害的领域,所以我们把界线画清楚。

作为模块交付: 带 MFA 透传的 Azure AD 联合、加固后的自托管 Authentik、OIDC 与 SAML2 应用注册、面向硬件的 LDAP 前哨、来自 Azure AD 的 SCIM 开通与注销(含会话失效)、基于用户组的访问策略、ERP 声明、阶梯式 MFA、应用门户、WhatsApp 与 3CX 绑定、M3 的 SAML2 适配、泰文界面、测试,以及双语文档。

按项目配置、不是独立模块: 通行密钥与 WebAuthn 的注册策略。Authentik 支持构建带有独立阶段与策略的专用注册流程,我们在通行密钥注册一文中提到的加固措施——注册前强制阶梯式验证、限制恢复路径、特权角色凭据变更时告警——会作为策略工作的一部分,为有需要的客户配置,但它不是价目表上单独一行的现成功能。把身份事件接入 simpliSOC 这类 SIEM 也是同理:日志本身已经存在,接入告警需要单独定范围。企业微信、钉钉等国内常用办公平台的账号绑定,同样可以用自定义阶段实现,但不在标准模块清单内,需要按项目评估。

不在范围内: 硬件本身。打印机、标签系统与机器人由客户自备;simpliSSO 在技术可行的范围内提供门户深链接,但不会更换或重新配置设备固件。

九、适合什么样的企业

simpliSSO 适合已经在使用 Microsoft 365(或其他符合标准的目录服务)、拥有十几到几十套内部系统、并且至少有一套纯 SaaS 型 SSO 会落下的老旧系统的组织。尤其适合交付之后希望由自己的运维团队在自有基础设施上持有和运行这套系统的企业:一台 4 vCPU / 8 GB 的主机上用 Docker Compose 运行,配置以带版本的 Blueprint YAML 保存,而不是存在某个人的脑子里。

反过来,如果你只有五个 SaaS 工具、没有任何本地系统,托管型身份服务会更简单。

常见问题

simpliSSO 会取代 Azure AD 吗?

不会。Azure AD 仍然是权威目录,继续负责密码、MFA 和条件访问。Authentik 不保存员工密码,而是向上与 Azure AD 联合,向下给各个应用签发令牌。

没有 Microsoft 365 能用吗?

能。Authentik 可以与 Google Workspace、Okta、通用 OIDC 或 SAML2 身份源联合,也可以为无法依赖云目录的场景直接对接本地 Active Directory / OpenLDAP。

员工离职后,访问权限会怎样?

IT 在 Azure AD 中停用一次账号,SCIM 把变更推送到 Authentik,活跃会话失效,所有已接入的应用不再接受该身份。如果在用通行密钥等认证器,建议在策略配置中把"离职时删除已注册凭据"也纳入流程——账号已停用但认证器仍处于绑定状态,存在被重新启用的风险。

包含通行密钥吗?

通行密钥注册的加固作为策略工作的一部分按项目配置,不作为独立模块交付。详见第八节。

额外编写的代码归谁所有?

所有定制 Python 代码——策略、映射与阶段——在尾款支付后都归客户所有。

如何报价?

按每次部署报价,在范围沟通后给出固定价格。必选模块为 F-01、F-02、F-03,其余模块可在签约前增加、分期或删减。

---

如果数一数自己环境里的登录入口,结果让你不太安心,欢迎告诉我们应用数量、使用的协议以及上游目录服务,我们会在一次沟通内给出固定价格方案:hello@simplico.net,电话 (+66) 97 496 6397,WhatsApp (+66) 83 001 0222,LINE ID:iiitum1984。完整架构与接入示例见 simpliSSO 产品页。

---

来源:

• simpliSSO — Simplico
• 通行密钥的「注册」才是新的攻击面 — Simplico
• 你的员工有24个密码,你的企业就有24个攻击面 — Simplico
• 潜伏在工程团队中的安全隐患 — Simplico