業(yè)務(wù)系統(tǒng)的增多導(dǎo)致用戶信息、用戶登錄不便于統(tǒng)一管理, 基于此我們開始對單點登錄SSO和統(tǒng)一身份認證服務(wù)CAS進行探索. 當前我們的科研管理系統(tǒng)已經(jīng)開發(fā)的差不多了，由于每次開發(fā)學(xué)校的項目都需要導(dǎo)入教師信息，多個系統(tǒng)就造成了用戶數(shù)據(jù)難統(tǒng)一管理，多個系統(tǒng)之間的用戶賬號密碼難管理，于是這幾天我們在科研系統(tǒng)開發(fā)基礎(chǔ)上提出了第二方案，使用統(tǒng)一身份認證服務(wù)CAS對我校教師賬戶信息進行管理。

說實話，我們可以系統(tǒng)已經(jīng)開發(fā)近九成，系統(tǒng)業(yè)務(wù)早已成型，如果實行這個方案需要對后端進行一部分重構(gòu)。后端是基于eladmin簡化過的框架，雖說這樣動后端原框架中的也是比較費力的，首先需要對框架有一定了解，其次對業(yè)務(wù)熟悉，會涉及到mybatispuls一對多，一對一的結(jié)構(gòu)，解耦用戶信息緩存，修改安全框架。當時我們甚至懷疑自己是否能完成這個任務(wù)，在小桑的學(xué)長的指導(dǎo)和參與改進的幾個人的討論交流下，我們最終決定嘗試嘗試。

我相信我們最終肯定能做出來，以后能服務(wù)更多的項目，我對大家有信心。

差點誤入歧途。起初我們本想走微信公眾/小程序那套認證流程，在科研管理系統(tǒng)后端通過appId和secret來認證訪問我們的系統(tǒng)，但最后發(fā)現(xiàn)著并不是CAS的認證流程，CAS只完成用戶賬戶認證，因為之前沒有接觸過SSO和CAS，我們這可的業(yè)務(wù)也不僅僅涉及身份驗證，導(dǎo)致我們的登錄認證流程老是乖乖的，成了個四不象，最終在前幾天中午我們跟小桑學(xué)長的一次討論中撥開了縈繞大腦的迷霧。

我們終于搞清楚了CAS認證原理，簡單白話說一下。首先它在功能上它只完成用戶身份認證，驗證通過給票據(jù)，在業(yè)務(wù)系統(tǒng)通過票據(jù)換取用戶信息。為什么CAS能實現(xiàn)多個業(yè)務(wù)系統(tǒng)統(tǒng)一登錄呢？首先它有個公共的登錄頁面(還有其他的不止這些)，這個頁面屬于CAS，當我們通過域名訪問該頁面，通過賬號密碼認證通過CAS會在二級域名下的cookie保存用戶登錄的證明（類似token但不是，我們稱它TGT，用它可以到CAS換取業(yè)務(wù)票據(jù)ST），同時也會帶著ST（Service Ticket，用來換取用戶信息，一般只用一次）重定向到所要登錄的業(yè)務(wù)系統(tǒng)，該系統(tǒng)拿到ST會向CAS換用戶信息（到這里CAS的任務(wù)就完成了），之后拿到用戶信息與自己的數(shù)據(jù)庫比對無誤就讓用戶登錄，此時該業(yè)務(wù)系統(tǒng)會給登錄創(chuàng)建一個token并保存在業(yè)務(wù)系統(tǒng)域名下，實現(xiàn)下次免登，從中我們可以看出CAS做的事很簡單，就是驗證賬戶和返回賬戶信息，之后就與CAS無關(guān)了。

未完待續(xù)。

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

文章同步更新到我的個人博客：https://elltor.com/