前言
本期介紹一下CAS（Central Authentiction Service ）中心認證服務，以Apereo CAS工程爲核心講解CAS是怎麼解決商業級系統SSO（single sign-on）認證問題的。
目錄
一，SSO與SLO
在介紹CAS工作之前，要先從SSO的故事講起。SSO（single sign-on）單點登陸和SLO（single logout)單點登出是分佈式系統認證中一個經典問題。SSO的定義是在多個應用系統中,用戶只需要登錄一次就可以訪問所有相互信任的應用系統.
首先要明白我們爲什麼要登陸系統？
當我們瀏覽器做訪問請求服務器操作時，由於http協議是無狀態的，並不會記錄訪問者的信息，這樣服務器就分不清是哪個用戶在發送請求，如果要攜帶客戶端信息就要在http報文頭上加用戶信息字段，定製化的http就使用cookie來攜帶客戶端用戶的信息，帶入到服務器中轉化成服務器可處理的session去識別這個發送請求的用戶到底是誰。
SSO存在的意義
如果在一個系統上，問題就很好理解，客戶端通過cookie攜帶信息，服務器拿到請求的session提取用戶信息往往就要開始做信息認證和權限審覈了。然而在分佈式系統場景，我們往往需要把不同模塊拆分成不同系統來合理利用資源，降低系統的耦合性；或者不同的集羣節點上允許不同的服務，當兩個服務需要相互建立業務關係時就會面對一個問題，如何整合兩個不同系統的認證系統使得用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
當然這個過程中用戶其實是要完全無感的，人家使用你的系統總不能一直重複登陸登出系統吧。即使在內部也不能連續在多個系統中做信息定向認證，每個系統權限模型都不一樣，可能需要大量的精力去調和各個權限系統的差別。所以我們的需求是獨立設計一個權限認證系統來做全部系統的SSO，用戶登陸後在服務器產生SSO session做認證和權限，成功登陸後生成一個TGT(ticket-granting ticket)，並通過攜帶這個TGT token形成ST(service ticket)服務票據通過瀏覽器訪問各個服務。當用戶登出系統時SLO操作銷燬生成的SSO session，登出後用戶再去請求服務就會因爲沒有session的token而報錯。
二，CAS系統架構
如何去實現一個商業級的單點登陸的認證系統，首先客戶端方面，它需要支持衆多的客戶端協議（如CAS, SAML, OAuth, OpenID）來滿足服務的擴展性；其次後端方面也需要支持衆多的數據源（如LDAP, database, X.509, 2-factor）訪問權限；同時它也要支持很多客戶端的庫（如Java，PHP，.Net）。當然你自己系統的權限模型要在你自己的權限系統上實現，如何接CAS系統和如何設計CAS系統是兩回事。
那麼Apereo CAS給了一個很好的答案去實現這樣的認證系統：
fig.1 CAS 架構
可以看到CAS系統從上到下分別是用戶的web層終端，處理web報文檢查ST並路由的CAS client，處理session信息實現SSO功能的CAS server，以及後端存儲權限信息的數據源。
三，CAS client
CAS client做了兩部分工作，一是通過各種協議和CAS server交互做SSO通訊，以Filter方式保護受保護的資源,對於訪問受保護的資源的每個Web請求, 會分析該請求的Http請求中是否包含Server ticket，並在需要登錄時,重定向到CAS Server，如果得到ST則直接定向到service。
另一方面打成軟件包嵌入到用戶的平臺去使用。所以CAS client作爲一個獨立的項目被分成很多版，比如Java-cas-client，.NET-cas-client等。
四 , CAS server
CAS server是依賴於Spring Framework 來做用戶的認證和權限請求處理的上層交互的，具體從client到server的交互如下圖：
fig.2 CAS認證過程
而在用戶的視角可能只是上圖中的登陸框，在輸入密碼之後點擊確定，CAS server會將信息與後端數據源交互認證，認證成功後在server生成與用戶id對應的TGT併產生SSO session，用戶請求通過攜帶TGT作爲token包裝成URL中的ST重定向到其他服務。如果在其他服務中發生錯誤或者退出，ST認證失敗則默認重定向到登陸界面。所有與CAS的交互均採用SSL協議,確保,ST和TGC的安全性。
五，CAS protocol
CAS protocol是定義在CAS client和server之間的基於HTTP的簡單協議，現在有v1,v2,v3三個版本，CAS對應的URI表如下：
| URI | Description |
|---|---|
/login |
credential requestor / acceptor |
/logout |
destroy CAS session (logout) |
/validate |
service ticket validation |
/serviceValidate |
service ticket validation [CAS 2.0] |
/proxyValidate |
service/proxy ticket validation [CAS 2.0] |
/proxy |
proxy ticket service [CAS 2.0] |
/p3/serviceValidate |
service ticket validation [CAS 3.0] |
/p3/proxyValidate |
service/proxy ticket validation [CAS 3.0] |
協議對應登陸登出制定了很多參數，返回值和錯誤碼，一個簡單登陸的URI例子：
Simple login example:
https://server/cas/login?service=http%3A%2F%2Fwww.service.com
CAS 協議中還提供了Poxy(代理)模式,來解決更復雜的場景，比如代理服務器會加上代理認證票據字段做真正服務的SSO功能，具體關於CAS protocol proxy可見：https://blog.csdn.net/aaronsimon/article/details/82698776
參考：
1. https://github.com/apereo/cas