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