一个典型的高校现状
一所中等规模本科院校，通常已经建设了教务、学工、图书、一卡通、宿管、科研、财务、资产等十余套系统，分属五六个厂商，建设时间跨度可能超过十年。
对师生来说，体感是这样的：办一件事要登录三个系统，记三套密码，其中两个密码规则还不一样；查一个数据要跑两个部门，两边给出的数字对不上。
新建一套应用，能解决其中一个问题，同时制造一个新的孤岛。
为什么身份要排在最前面
身份是所有系统的公共前置依赖。它有三个特性使其必须优先处理：
其一，身份是唯一的强关联键。 教务的学号、一卡通的卡号、图书的读者号，最终都指向同一个人。如果没有统一的人员主键，任何跨系统的数据关联都是不可靠的字符串匹配。
其二，身份决定权限边界。 "谁能看什么数据"这个问题，在没有统一身份的情况下只能在每个系统里各答一遍，结果必然不一致——常见的情况是某位教师调岗半年后，仍能访问原部门的敏感数据。
其三，身份是体验的第一道门槛。 单点登录带来的体验提升是所有师生立刻可感知的，这为后续项目争取了组织支持。这一点在实际推进中的价值不容低估。
权威源的确定
建身份中台的第一个技术决策是：人员数据以谁为准。
我们的通行做法是：
- 教职工以人事系统为权威源；
- 学生以学籍系统为权威源；
- 校外人员（合作单位、临时访客）由统一身份中台自行管理。
权威源确定后，其他系统一律订阅，不允许自行新增人员。这条纪律看似严苛，但一旦松口，孤岛会立刻重新长出来。
生命周期比登录更重要
很多学校的单点登录做完就宣告结束，但真正麻烦的是生命周期管理：
- 学生入学 → 账号自动开通，权限按年级专业分配；
- 学生转专业 → 权限自动调整，历史数据归属保留；
- 学生毕业 → 账号转为校友态，教务权限回收，邮箱与图书保留一段时间；
- 教师离职 → 账号即时冻结，数据交接流程触发。
没有生命周期管理的身份系统，运行两年之后就会积累大量僵尸账号，成为安全隐患。这类账号往往在安全审计时才被发现，而那时清理成本已经很高。
分步实施路径
第一阶段（4–6 周）：身份底座。 建立人员主数据与统一账号体系，接入 CAS/OAuth2，先打通 3–5 套高频系统验证可行性。
第二阶段（8–12 周）：横向覆盖。 逐步接入剩余系统。老旧系统若不支持标准协议，可采用代理登录方式过渡。
第三阶段（持续）：应用建设。 在统一底座上建设服务大厅、数据看板等应用。此时新建应用不再制造孤岛，而是在放大底座价值。
一条务实的建议
不要在项目一开始就承诺"打通所有系统"。有些系统的厂商已经不再提供服务，有些接口改造需要额外付费，这些现实约束会在推进中一一浮现。
更可行的做法是按使用频次排序，先打通覆盖 80% 使用场景的那几套系统。师生的体验改善会成为后续推进的最好推力。