CAS單點登入（一）——單點登入與CAS理論介紹
一、什麼是單點登入（SSO）
單點登入主要用於多系統整合，即在多個系統中，使用者只需要到一箇中央伺服器登入一次即可訪問這些系統中的任何一個，無須多次登入。
單點登入（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。
二、web系統如何實現單點登入
目前已經有了成熟的單點登入實現方案，比如CAS，我們只要在web系統中應用單點登入方案CAS即可。(主要涉及到註冊登入驗證等模組的改動)。
三、什麼是CAS
CAS (Central Authentication Service) 是耶魯 Yale 大學發起的一個java開源專案，旨在為 Web應用系統提供一種可靠的 單點登入 解決方案（ Web SSO ）， CAS 具有以下特點：
-
- 開源的企業級單點登入解決方案；
- CAS Server 為需要獨立部署的 Web 應用----一個獨立的Web應用程式(cas.war)。 ；
- CAS Client 支援非常多的客戶端 ( 指單點登入系統中的各個 Web 應用 ) ，包括 Java, .Net, PHP, Perl, 等。
CAS在2004年12月成立Jasig專案，所以也叫JA-SIG CAS。
官網1：https://apereo.github.io/cas/5.2.x/index.html
官網2： https://www.apereo.org/projects/cas/about-cas
論壇：http://jasig.275507.n4.nabble.com/Jasig-CAS-f275508.html
github：https://github.com/apereo/cas
開發者快捷資源：http://developer.jasig.org/
下載連結：https://www.apereo.org/projects/cas/download-cas
官網開發文件：https://apereo.github.io/cas/5.2.x/installation/Configuring-Commandline-Shell.html
中文開發文件：http://www.cassso-china.cn/apereo_github_cas_5.2//apereo.github.io/cas/5.2.x/
四、CAS原理
從結構上看， CAS 包含兩個部分： CAS Server 和 CAS Client 。
1、CAS Server
CAS Server 需要獨立部署，主要負責對使用者的認證工作， 它會處理使用者名稱 / 密碼等憑證 (Credentials) 。
CAS Server 負責完成對使用者的認證工作， 需要獨立部署。並且有不止一種 CAS Server 的實現， Yale CAS Server 和 ESUP CAS Server 都是很不錯的選擇。
CAS Server 會處理使用者名稱 / 密碼等憑證 (Credentials) ，它可能會到資料庫檢索一條使用者帳號資訊，也可能在 XML 檔案中檢索使用者密碼，對這種方式， CAS 均提供一種靈活但同一的介面 / 實現分離的方式， CAS 究竟是用何種認證方式，跟 CAS 協議是分離的，也就是，這個認證的實現細節可以自己定製和擴充套件。
2、CAS Client
CAS Client 部署在客戶端， 負責處理本地 Web 應用（客戶端）受保護資源的訪問請求，並且當需要對請求方進行身份認證時，重定向到 CAS Server 進行認證 。
CAS Client 負責部署在客戶端（注意，是指 Web 應用），原則上， CAS Client 的部署意味著，當有對本地 Web 應用的受保護資源的訪問請求，並且需要對請求方進行身份認證， Web 應用不再接受任何的使用者名稱密碼等類似的 Credentials ，而是重定向到 CAS Server 進行認證。
目前， CAS Client 支援（某些在完善中）非常多的客戶端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客戶端，幾乎可以這樣說， CAS 協議能夠適合任何語言編寫的客戶端應用。
3、CAS相關詞彙和概念
(後面程式碼小節會詳細介紹，這裡初步瞭解即可)
TGC(ticket-granting cookie) —— 授權的票據證明，由 CAS Server 通過 SSL 方式傳送給終端使用者；
KDC( Key Distribution Center ) —— 金鑰發放中心；
ST (Service ticket) —— 服務票據， 由 KDC 的 TGS 發放， ST 只能被嘗試驗證一次。 任何一臺 Workstation 都需要擁有一張有效的 Service Ticket 才能訪問域內部的應用 (Applications) 。 如果能正確接收 Service Ticket ，說明在 CASClient-CASServer 之間的信任關係已經被正確建立起來，通常為一張數字加密的證書；
Ticket Granting tieckt(TGT) —— 票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交 Credentials （憑證或身份認證資訊 ) ；
Authentication Service (AS) —— 認證服務，索取 Crendential ，發放 TGT ；
Ticket-Granting Service (TGS) —— 票據授權服務，索取 TGT ，發放 ST 。
4、CAS協議和工作流程
下圖是 CAS 基礎協議：
（1）CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求， CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，如果沒有，則說明當前使用者尚未登入，於是將請求重定向到指定好的 CAS Server 登入地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登入成功過後轉回該地址。使用者在第 3 步中輸入認證資訊，如果登入成功， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並快取以待將來驗證，之後系統自動重定向到 Service 所在地址，併為客戶端瀏覽器設定一個 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新產生的 Ticket 過後，在第 5 ， 6 步中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
（2）在該協議中，所有與 CAS 的互動均採用 SSL 協議確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向的過程，但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於使用者是透明的。
（3）CAS 如何實現 SSO
當用戶訪問另一服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：
1) 如果 User 的持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
2) 如果 TGC 失效，那麼使用者還是要重新認證 ( 走基礎協議圖的 Step3) 。
另外，CAS 協議中還提供了 Proxy （代理）模式，以適應更加高階、複雜的應用場景，具體介紹可以參考 CAS 官方網站上的相關文件。
原文：https://blog.csdn.net/zzq900503/article/details/54646828