思考｜使我校教职工账户实现 CAS

业务系统的增多导致用户信息、用户登录不便于统一管理, 基于此我们开始对单点登录 SSO 和统一身份认证服务 CAS 进行探索. 当前我们的科研管理系统已经开发的差不多了，由于每次开发学校的项目都需要导入教师信息，多个系统就造成了用户数据难统一管理，多个系统之间的用户账号密码难管理，于是这几天我们在科研系统开发基础上提出了第二方案，使用统一身份认证服务 CAS 对我校教师账户信息进行管理。

说实话，我们可以系统已经开发近九成，系统业务早已成型，如果实行这个方案需要对后端进行一部分重构。后端是基于 eladmin 简化过的框架，虽说这样动后端原框架中的也是比较费力的，首先需要对框架有一定了解，其次对业务熟悉，会涉及到 mybatispuls 一对多，一对一的结构，解耦用户信息缓存，修改安全框架。当时我们甚至怀疑自己是否能完成这个任务，在小桑的学长的指导和参与改进的几个人的讨论交流下，我们最终决定尝试尝试。

我相信我们最终肯定能做出来，以后能服务更多的项目，我对大家有信心。

差点误入歧途。起初我们本想走微信公众/小程序那套认证流程，在科研管理系统后端通过 appId 和 secret 来认证访问我们的系统，但最后发现着并不是 CAS 的认证流程，CAS 只完成用户账户认证，因为之前没有接触过 SSO 和 CAS，我们这可的业务也不仅仅涉及身份验证，导致我们的登录认证流程老是乖乖的，成了个四不象，最终在前几天中午我们跟小桑学长的一次讨论中拨开了萦绕大脑的迷雾。

我们终于搞清楚了 CAS 认证原理，简单白话说一下。首先它在功能上它只完成用户身份认证，验证通过给票据，在业务系统通过票据换取用户信息。为什么 CAS 能实现多个业务系统统一登录呢？首先它有个公共的登录页面(还有其他的不止这些)，这个页面属于 CAS，当我们通过域名访问该页面，通过账号密码认证通过 CAS 会在二级域名下的 cookie 保存用户登录的证明（类似 token 但不是，我们称它 TGT，用它可以到 CAS 换取业务票据 ST），同时也会带着 ST（Service Ticket，用来换取用户信息，一般只用一次）重定向到所要登录的业务系统，该系统拿到 ST 会向 CAS 换用户信息（到这里 CAS 的任务就完成了），之后拿到用户信息与自己的数据库比对无误就让用户登录，此时该业务系统会给登录创建一个 token 并保存在业务系统域名下，实现下次免登，从中我们可以看出 CAS 做的事很简单，就是验证账户和返回账户信息，之后就与 CAS 无关了。

未完待续。

于 2020-12-5 周六，夜已深，倦鸟。