開源認證組件彙總 Kerberos和CAS

1、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

2、CAS 統一認證中心

CAS是Central Authentication Service的縮寫，中央認證服務，一種獨立開放指令協議。CAS 是 Yale 大學發起的一個開源項目，旨在爲 Web 應用系統提供一種可靠的單點登陸方法，CAS 在 2004 年 12 月正式成爲 JA-SIG 的一個項目。

特色

編輯

一、開源的企業級單點登陸解決方案。

二、CAS Server 爲須要獨立部署的 Web 應用。

三、CAS Client 支持很是多的客戶端(這裏指單點登陸系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

四、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 隨機產生一個至關長度、惟1、不可僞造的 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 官方網站上的相關文檔。