作者：京東物流?趙勇萍
前言
上個月我負責的系統(tǒng)SSO升級，對接京東ERP系統(tǒng)，這也讓我想起了之前我做過一個單點登錄的項目。想來單點登錄有很多實現(xiàn)方案，不過最主流的還是基于CAS的方案，所以我也就分享一下我的CAS實踐之路。
什么是單點登錄
單點登錄的英文名叫做：Single Sign On（簡稱SSO）。SSO的定義是在多個應用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統(tǒng)。之前我做的系統(tǒng)，需要需要設計一套支持單點登錄的鑒權認證系統(tǒng)，所有系統(tǒng)都基于一套鑒權系統(tǒng)進行登錄，并且可以實現(xiàn)各個系統(tǒng)之間的互信和跳轉。所以就采用了CAS架構。
什么是CAS
CAS架構的核心是需要搭建一個CAS Server，該服務獨立部署，擁有獨立三級域名，主要負責對用戶的認證工作。他主要組成包括WEB前端提供登錄頁面，票據(jù)模塊，認證模塊。
核心票據(jù)：
a. TGT(Ticket Grangting Ticket)：TGT是CAS為用戶簽發(fā)的登錄票據(jù)，有TGT就表明用戶在CAS上成功登錄過。用戶在CAS認證成功后，會生成一個TGT對象，放入自己的緩存中(Session)，同時生成TGC以cookie的形式寫入瀏覽器。當再次訪問CAS時，會先看cookie中是否存在TGC，如果存在則通過TGC獲取TGT，如果獲取到了TGT則代表用戶之前登錄過，通過TGT及訪問來源生成針對來源的ST，用戶就不用再次登錄，以此來實現(xiàn)單點登錄。
b. TGC(Ticket-granting cookie)：TGC就是TGT的唯一標識，以cookie的形式存在在CAS Server三級域名下，是CAS Server 用來明確用戶身份的憑證。
c. ST(Service Ticket)：ST是CAS為用戶簽發(fā)的訪問某一客戶端的服務票據(jù)。用戶訪問service時，service發(fā)現(xiàn)用戶沒有ST，就會重定向到 CAS Server 去獲取ST。CAS Server 接收到請求后，會先看cookie中是否存在TGC，如果存在則通過TGC獲取TGT，如果獲取到了TGT則代表用戶之前登錄過，通過TGT及訪問來源生成針對來源的ST。用戶憑借ST去訪問service，service拿ST 去CAS Server 上進行驗證，驗證通過service生成用戶session，并返回資源。
基于CAS的系統(tǒng)實踐方案
1. 業(yè)務背景
在我負責的項目系統(tǒng)中，后臺業(yè)務采用的是微服務架構，有統(tǒng)一的業(yè)務網(wǎng)關，所以基于統(tǒng)一的業(yè)務網(wǎng)關，整合客戶其他系統(tǒng)登錄鑒權流程。具體業(yè)務架構圖如下：
在此說明一下，因為登錄系統(tǒng)的用戶體系在不同的系統(tǒng)中，所以我在設計SSO統(tǒng)一登錄認證的時候，把SSO系統(tǒng)與業(yè)務系統(tǒng)結構出來。而用戶體系有兩套，一套叫做采方用戶體系，一套叫做供方用戶體系。所以才會有如圖所示的SSO Server服務，他本身不負責用戶管理，但會通過統(tǒng)一標準接口的方式實現(xiàn)控制反轉，實現(xiàn)對用戶服務的調用。
2. 單點登錄時序圖
時序圖如下：
如圖所示，時序圖標識的是兩個系統(tǒng)通過SSO服務，實現(xiàn)了單點登錄。
3. 單點登錄核心接口說明
3.1 sso認證跳轉接口
調用說明：
由應用側發(fā)起調用認證中心的接口。
URL地址：
https:// sso.com?appId=***&tenantType=1&redirectUri=***
請求方式：302重定向
參數(shù)說明：
appId: 對接SSO認證中心的應用唯一標識,由SSO認證中心通過線下的方式頒發(fā)給各個應用系統(tǒng)。
tenantType: 標記是供方登錄還是采方登錄。采方為1，供方為2.
RedirectUri: 應用回調地址。
3.2 重定向獲取臨時令牌code接口
調用說明：
有認證中心發(fā)起，應用側需實現(xiàn)的接口。認證中心通過302重定向，將code傳給應用側，應用側自行發(fā)起通過臨時令牌code換取accessTokenInfo。
URL地址：
https://應用域名?code=***
請求方式：GET
參數(shù)說明：
Code: 臨時令牌，有效時間5min
3.3 獲取accessTokenInfo接口
調用說明
由應用側發(fā)起調用認證中心的接口。通過該接口可以獲取accessTokenInfo信息，然后系統(tǒng)自行生成本系統(tǒng)session信息。
URL地址:
https://sso.com/api/token/create?grantType=authorization_code&appId=yuncai&code=***
請求方式：GET
參數(shù)說明：
appId: 對接SSO認證中心的應用唯一標識,由SSO認證中心通過線下的方式頒發(fā)給各個應用系統(tǒng)。
code: 臨時令牌,需加密
加密規(guī)則如下:
-
Code先進行base64加密
-
用認證中心給的privateKey進行加密（RSA加密）。
-
加密后進行URLCode轉碼。
返回參數(shù)：
{
“accessToken”: “****”, //token令牌
“expiresIn”: 7200, //過期時間
“user”: {
“username”: “zhangsan”,
“fullName”: “張三”,
“userId”: “1212”,
“phone”: “13100000000”,
“email”: zhangsan@test.com,
“tenantId”: “S2131123”,
“tenantType”: 1
}
}
3.4 刷新Token接口
調用說明：
由應用側發(fā)起調用認證中心的接口。當token快到失效期時，通過該接口可以刷新accessTokenInfo信息，然后系統(tǒng)自行生成本系統(tǒng)session信息。
URL地址:
https://sso.com/api/token/refresh?appId=yuncai&accessToken=***
請求方式：GET
參數(shù)說明：
appId: 對接SSO認證中心的應用唯一標識,由SSO認證中心通過線下的方式頒發(fā)給各個應用系統(tǒng)。
accessToken: 需要刷新的token值。
4. 單點登出邏輯
有單點登錄，也會有單點登出，這樣才會形成業(yè)務閉環(huán)，對于單點登出邏輯，基本類似登錄的逆操作，時序圖如下：
5. 單點登出核心接口說明
5.1 登出sso認證中心跳轉接口
調用說明：
由應用側發(fā)起調用認證中心的接口。
URL地址：
https://sso.com/logout?redirectUri=***
請求方式：GET
參數(shù)說明
RedirectUri: 應用回調地址。
5.2 應用系統(tǒng)退出接口
調用說明
有認證中心發(fā)起，應用側需實現(xiàn)的接口。通過該接口觸發(fā)個應用系統(tǒng)清除緩存和session相關信息，實現(xiàn)系統(tǒng)登出。
URL地址：
https://應用系統(tǒng)域名/ssoLogout
請求方式：GET
header: logoutRequest:=accessToken
總結
對于CAS這種單點登錄的架構，他是非常依賴于cookie的安全性的。所以CAS的安全性也在一定程度上取決于cookie的安全性，所有增強cookie安全性的措施，對于增強CAS都是有效的。文章來源：http://www.zghlxwxcb.cn/news/detail-412322.html
最后提一句，一定要使用HTTPS協(xié)議哦。文章來源地址http://www.zghlxwxcb.cn/news/detail-412322.html
到了這里，關于【實踐篇】基于CAS的單點登錄實踐之路的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
