基於認證中心的單點登錄系統CAS

本文描述了基於認證中心的單點登錄系統，採用獨立的認證中心是實現企業單點登錄非常好的應用實踐。

CAS需要較高的集成度，在需要實現單點登錄的系統，配置認證中心地址，和認證中心交互獲得用戶信息。

文尾比較了，通過子域名方式和Oauth方式實現單點登錄系統的差別。

基於認證中心的單點登錄原理是基於ticket實現。CAS系統就是一個集成化程度很好的基於ticket單點登錄系統。

單點登錄步驟如下：

1.用戶訪問應用App Server，AppServer首先要判斷用戶是否登錄。在之間的文章，論證過Http協議的無狀態屬性，用戶的登錄狀態採用cookie保存session_id，通過session_id獲得session信息，session保存在AppServer中，從AppServer內存中獲得Http協議的會話信息。

2.當採用CAS結構時，需要配置CAS server，並在App Server上集成CAS client。CAS server要獨立配置，CAS client部署在App Server上。App client 集成CAS client sdk，在配置文件中設置攔截器和CAS server的地址，實現認證訪問。

（問題：在攔截器中，要過濾session，存儲CAS server 返回的信息，這部分代碼應該由用戶完成）

3.如果用戶沒有登錄，採用http 302協議重定向到認證服務中心CAS_Server，在CAS_Server完成用戶的登錄(以用戶名密碼方式驗證用戶)，CAS_Server生成TGT (Ticket Granting Ticket)，並保存在cookie中，TGT的cookie domain爲CAS_Server，並返回App的ticket ST。

4.將2中的App Server定義爲App_1，重定向時App_1 URL作爲參數拼接在CAS_Server URL中，CAS server會保存App_1和用戶信息。拼接App_1 URL和ST，使用戶重定向到App_1。

5.App_1在攔截器中獲取用戶的ST_1，用ST_1向CAS_server換取用戶信息，並完成本地登錄local login。此時，用戶完成全局global login和本地login。

6.當用戶訪問App_2時，App_2通過判斷是否存在本地登錄local login(此時用戶完成了全局login，但沒有本地login)，會重定向到CAS server，CAS server通過cookie中的TGT實現身份認證，並給用戶頒發ST_2，返回302重定向信息返回App_2。

7.App_2獲取用戶ST_2(CAS server返回重定向信息時，將ST2拼接在App_2 URL中)，App_2向CAS server驗證ST2信息，並獲取用戶信息，完成用戶在App_2中的local login。

單點登出步驟：

1.用戶在App_1完成登出操作。

2.App_1向CAS Server發出請求進行全局登出。

3.CAS Server向App_2發出消息，完成用戶登出。

代理模式

代理模式是爲了解決App_1代理用戶身份訪問App_2的資源。爲什麼會有這個feature，或者說這個需求從哪裏來？

• App_2已經被CAS client保護了，App_1無法直接訪問App_2資源信息。
• App_2不信任App_1，安全要求必須要獲得用戶身份。

一般情況，在App_1和App_2之間通過接口直接訪問。

CAS缺點&問題：

1.CAS 必須配置Https，通過url傳遞ST，ST沒有被加密。在安全性上，ST的只能使用一次，並且只有較短的生存時間。

2.應用系統建成後，改造代價比較大。適合初建系統。

和Oauth系統的比較

1.登錄方式是一致的，在Oauth服務處登錄，重定向到App url+code ，App通過code獲取用戶信息。

2.Oauth採用jwt返回App，那麼用戶不能完成單點登出操作。

3.Oauth用作Proxy模式，jwt中獲取token，通過token獲取Api權限。Token是加密的。

4.Oauth通常應用在三方登錄，爲用戶提供方便的登錄方式，系統本身還是具有用戶管理功能。

子域名方式比較：

1.子域名通過在父域名上設置全局cookie，標誌用戶身份。

2.子域名方式，需要全域共享session。

參考資料：

1. 單點登錄原理與簡單實現  https://www.cnblogs.com/ywlaker/p/6113927.html
2. 文檔 https://apereo.github.io/cas/5.0.x/protocol/CAS-Protocol.html#proxy-web-flow-diagram

不同域名的處理方法

參考：

1. Taobao SSO 跨域登錄過程解析   https://yanmingming.wordpress.com/2017/12/12/taobao-sso-%E8%B7%A8%E5%9F%9F%E7%99%BB%E5%BD%95%E8%BF%87%E7%A8%8B%E8%A7%A3%E6%9E%90/
2. 淘寶跨域獲取Cookie分析 https://www.oschina.net/question/4873_18517
3. 啥是單點登陸？淘寶和天貓是如何實現同時登陸的？ https://cloud.tencent.com/developer/article/1443036
4.  localStorage和cookie的跨域解決方案 https://www.haorooms.com/post/kuayu_localstorage_cookie
5.  跨域問題導致設置 cookie 不生效 https://zhuanlan.zhihu.com/p/35618124