学校里的系统常常不是一次规划出来的。教务、存储、报修、资源平台、人工智能工具，各自在不同时间上线，也各自带来一套账号。系统只有两三个时，教师多记几组密码似乎还能应付；当人员调动、学生升学、临时账号和权限回收一起出现，问题就不再是“登录麻烦”，而是学校无法用一套规则回答：这个人是谁、现在属于哪个部门、可以进入哪些系统、离校后什么时候停止访问。
前面两篇文章分别讨论了 SSO 应该从哪里起步，以及 校园门户为什么不能只做链接页。这一次，我想把两条线放回同一张架构图里：为什么校园环境需要统一门户，以及为什么我更愿意采用 OIDC + LDAP + 自建门户的组合。
门户的价值，不是把所有图标摆在一起
统一门户至少要承担三件事。第一，它是稳定的服务入口。教师不必记住每个系统的域名，而是按“提交材料”“查看班级文件”“使用 AI 工具”等任务找到服务。第二，它承接统一登录体验。用户从门户进入业务系统时，身份确认尽量在同一处完成，不再把密码交给每个应用。第三，它提供最小的运行信息：服务是否可用、谁可以使用、出现故障该找谁、有没有替代路径。
门户不能重做所有系统。教务系统仍负责成绩和学籍，存储系统仍负责文件权限，OpenWebUI 仍负责模型、知识库和会话；门户只汇聚摘要、入口、待办、状态和帮助，复杂业务与最终授权继续留在原系统。
SSO、OIDC 和身份源，分别回答三个问题
校园统一身份项目最容易在术语上走偏。SSO、OIDC、LDAP 经常出现在同一份方案里，却不属于同一个层次。把它们分开，很多架构争论会立刻清楚。
OpenID Connect 规范把提供认证与身份声明的一方称为 OpenID Provider，也就是身份提供方；需要这些结果的应用是 Relying Party，也就是 OIDC 客户端。用户在身份提供方完成认证，客户端收到并校验 ID Token，再建立自己的本地会话。SSO 是用户看到的结果，OIDC 是实现这种结果的一种协议，而身份源负责提供可信的人员与组织数据。
这也解释了为什么“所有系统都连 LDAP”不等于统一登录。应用若各自拿用户名和密码去做 LDAP Bind，虽然账号目录统一了，密码仍被多个应用直接处理，每个系统也仍有自己的登录页面、会话和异常处理。OIDC 的价值，是把认证集中到身份提供方，业务应用只接收经过校验的身份结果。
LDAP、Active Directory 和 Samba AD 不是并列协议
LDAP 是访问目录服务的协议。RFC 4511 描述了 LDAP 如何访问分布式目录服务，但它没有规定学校必须使用哪一种目录产品。OpenLDAP 可以实现通用 LDAP 目录；Microsoft Active Directory Domain Services（AD DS）则是一整套域服务，除目录外还结合了域加入、Kerberos、组策略、DNS 等能力；Samba 4 可以在 Linux 环境中作为兼容 Active Directory 的域控制器，提供集成的 LDAP、Kerberos 和 AD DNS 能力。
因此，选择底层账号系统时，我会先看学校真正需要什么：
如果目标主要是为自建 Web 应用提供统一的用户、组织和组，通用 LDAP 目录通常更轻量，也更容易围绕现有数据设计。
如果学校已经大量使用 Windows 域加入、组策略、共享打印、Kerberos 或 Windows 集成认证，AD DS 更符合既有管理方式。
如果希望在 Linux 服务器上提供 AD 兼容域能力，并且团队能承担 DNS、复制、备份和升级运维，Samba AD 是可考虑的实现，但它不是“给 Samba 文件共享加一个 LDAP”这么简单。
无论使用哪一种实现，都要先确定权威数据来源。人事、学籍或经过确认的校级主数据决定人员是否存在、属于哪个组织；目录负责承载账号和组；身份提供方负责认证并发出声明。若把姓名、手机号或邮箱当成永不变化的唯一标识，后续改名、换号和重名都会造成旧账号无法合并。更稳妥的是为每个人保留稳定、不可重复分配的内部标识。
为什么我选择 OIDC + LDAP + 自建门户
这套组合的关键不在于三个名词，而在于把职责拆成五层。
权威数据层：确定人员、组织、在校状态和变更来源。
目录层：LDAP 保存账号、组和必要属性，处理查询与生命周期同步。
认证联合层：身份提供方验证用户，并通过 OIDC 向应用签发可校验的身份声明。
门户服务层：自建门户按角色组织入口、待办、通知、服务状态和帮助信息。
业务应用层：教务、存储、OpenWebUI 等系统保留自己的数据、会话和权限规则。
我选择它，主要有四个理由。其一，Web 应用接入边界清楚。新系统只要支持标准 OIDC，就可以按统一模板登记客户端、回调地址和声明映射。其二，账号生命周期集中。停用目录账号或撤销身份提供方访问后，用户不应再获得新的业务会话。其三，门户可以按校园实际工作迭代，不必等待每个供应商重做首页。其四，底层目录与上层登录协议相对解耦，将来更换门户界面或增加应用，不必迁移每个系统里的密码。
不过，自建不等于全部自己造。OIDC 的令牌签名、密钥轮换、会话、MFA、审计和故障恢复都属于高风险能力，应使用经过验证的身份组件实现。自建门户更适合放在服务编排和校园流程这一层，而不是手写一套密码算法和令牌协议。
这套架构的限制，也要在开始前说清楚
统一身份会减少分散维护，却会提高核心组件的重要性。身份提供方或目录故障，可能同时影响多个系统；错误的组映射，也可能把权限问题快速放大。因此至少需要备份、监控、时间同步、可信 HTTPS、密钥轮换方案和受控的应急管理员入口。应急账号要限制使用范围并记录每次启用，不能变成大家都知道的第二套通用密码。
它也不适合所有系统。完全不支持 OIDC、SAML 或可信代理接入的旧软件，可能只能保留本地账号，或通过供应商接口逐步改造。核心教务、财务等高风险系统，不应成为第一个试点。更合适的起点是一个用户范围可控、日志完整、失败后能切回本地登录的应用。
还要接受一个现实：统一认证不等于统一权限。身份提供方可以告诉 OpenWebUI “这是某位教师，属于某些组”，但是否能使用某个模型、查看某个知识库，仍应由 OpenWebUI 的业务规则决定。全局身份组只传递稳定且必要的信息，不要把每个应用的临时角色都塞回 LDAP。
以 OpenWebUI 为例，接入 OIDC 要完成哪些映射
OpenWebUI 是适合做首批试点的应用之一：它面向 Web，官方提供通用 OIDC 配置，登录链路和组权限也容易观察。接入时，校园身份平台是身份提供方，OpenWebUI 是 OIDC 客户端。先在身份提供方创建一个客户端，再把双方的参数逐项对齐。
一次正常登录应当这样发生：用户先访问 OpenWebUI；OpenWebUI 把浏览器重定向到校园身份提供方；用户在那里完成认证；身份提供方只把短时授权码送回预先登记的回调地址；OpenWebUI 在服务端换取并校验令牌，确认 issuer、audience、签名和有效期，再以稳定的 subject 标识建立或关联本地用户。
组映射要比“登录成功”多做一步风险判断。OpenWebUI 当前官方文档说明，启用 OAuth 组管理后，登录时会严格同步声明中的组：令牌里没有的组可能从用户本地成员关系中移除，管理员用户的组又不会自动按同样方式更新。因此，不要一开始就把目录中的所有组全量传入。可以先选择一个普通教师组和一个测试项目组，验证加入、移除、重新登录后的变化，再决定是否启用自动建组和角色管理。
验收不能停在“出现了登录按钮”
我会用四类账号验证完整链路：正常教师、没有 OpenWebUI 使用权限的账号、已经停用的账号、组刚刚发生变化的账号。除了首次登录，还要检查重复登录、退出后重新进入、令牌过期、用户改名、组移除和身份服务暂时不可达时的结果。
日志至少要能回答：请求去了哪个 issuer，回调地址是否匹配，令牌为什么被拒绝，最终使用哪个属性关联本地用户，组同步做了哪些增删。还要保留受控的本地应急管理员入口，避免身份服务故障时连排查入口都失去。但应急入口只能用于恢复，不应成为绕开统一身份的日常通道。
门户侧也要验证回跳体验。用户从门户打开 OpenWebUI，登录后应回到原本要访问的服务，而不是落到一个无关首页；服务不可用时，门户应显示状态和帮助信息，而不是让用户反复点击同一个入口。
小结：先统一身份链路，再逐步统一服务体验
校园统一门户真正解决的，不是“把几十个网址放到同一页”，而是让身份、服务入口和账号生命周期形成一条可以解释、可以审计、可以恢复的链路。SSO 是用户得到的体验，OIDC 是应用之间传递认证结果的协议，LDAP、AD DS 或 Samba AD 是目录与域服务的不同实现，自建门户则负责把校园里的任务和服务组织起来。
OIDC + LDAP + 自建门户适合有一定运维能力、希望逐步整合自建和可配置 Web 应用的学校。第一步不是一次接完所有系统，而是画清五层职责，选一个可回退的试点应用；第二步是把入校、调岗、临时账号和离校四类变化跑通。只有人员变化和故障场景也能被正确处理，“一个入口”才真正变成统一门户。
参考资料
校园统一门户，为什么我选择 OIDC + LDAP
本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
评论交流
欢迎留下你的想法