一、Kerberos
1.Kerberos原理和工作機制
概述：Kerberos的工作圍繞着票據展開，票據類似於人的駕駛證，駕駛證標識了人的信息，以及其可以駕駛的車輛等級。
1.1 客戶機初始驗證
1.2獲取對服務的訪問
2.kerberos中的幾個概念
2.1 KDC：密鑰分發中心，負責管理發放票據，記錄授權。
2.2 域：kerberos管理領域的標識。
2.3 principal：當每添加一個用戶或服務的時候都需要向kdc添加一條principal，principl的形式為 主名稱／實例名@領域名。
2.4 主名稱：主名稱可以是用戶名或服務名，還可以是單詞host，表示是用於提供各種網絡服務（如ftp，rcp，rlogin）的主體。
2.5 實例名：實例名簡單理解為主機名。
2.6 領域：Kerberos的域。
---------------------
版權聲明：本文為CSDN博主「波波happy」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lovebomei/article/details/80004277
二、CAS 統一認證中心
CAS是Central Authentication Service的縮寫，中央認證服務，一種獨立開放指令協議。CAS 是 Yale 大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。
特點
1、開源的企業級單點登錄解決方案。
2、CAS Server 為需要獨立部署的 Web 應用。
3、CAS Client 支持非常多的客戶端(這里指單點登錄系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
4、CAS屬於Apache 2.0許可證，允許代碼修改，再發布（作為開源或商業軟件）。
原理和協議
編輯
從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。圖1 是 CAS 最基本的協議過程：
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket，如果沒有，則說明當前用戶尚未登錄，於是將請求重定向到指定好的 CAS Server 登錄地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登錄成功過后轉回該地址。用戶在第 3 步中輸入認證信息，如果登錄成功，CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket，並緩存以待將來驗證，之后系統自動重定向到 Service 所在地址，並為客戶端瀏覽器設置一個 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新產生的 Ticket 過后，在第 5，6 步中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS 的交互均采用 SSL 協議，確保，ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向的過程，但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的。
另外，CAS 協議中還提供了 Proxy （代理）模式，以適應更加高級、復雜的應用場景，具體介紹可以參考 CAS 官方網站上的相關文檔。