(這段時間打算做單點登入，因此研究了一些cas資料並作為一個系列記錄下來，一來可能會幫助一些人，二來對我自己所學知識也是一個鞏固。)

一、為什麼要實現單點登入

隨著資訊化不斷髮展，企業的資訊化過程是一個循序漸進的過程，在企業各個業務網站逐步建設的過程中，根據各種業務資訊水平的需要構建了相應的應用系統，由於這些應用系統一般是 在不同的時期開發完成的，各應用系統由於功能側重、設計方法和開發技術都有所不同，也就形成了各自獨立的使用者庫和使用者認證體系。隨著新的業務網站不斷的增 加，使用者在每個應用系統中都有獨立的賬號，這樣就造成在訪問不同的應用系統時，需要記錄對應的使用者名稱和密碼，多個使用者名稱密碼極易記混，如果忘記或記錯了某 一個業務網站的使用者名稱或密碼就無法進行登入，耽誤工作，影響工作效率，隨著局內資訊化程序的推進還會有新的應用系統產生，如果不引入單一使用者登入的解決方 案，全公司工作人名特別是承擔審批許可權的各級領導很難記清各類應用系統的使用者名稱和密碼，嚴重影響由資訊化帶來快捷性和高效性。此外，多個應用平臺就有多個 使用者管理，這也為系統管理員維護人員系統帶來巨大的工作量，例如，一次變更10個人員，即使只有5個應用系統，也需要重複維護50個人員資訊，而企業的每 次人員調整遠不至10人，這種幾何增長的維護工作量，會浪費大量的精力和時間，減弱了資訊化系統帶來方便快捷，為此，需建立一套統一的、完善的、科學的單 點登入系統，每個使用者只需記錄一個使用者名稱密碼，登入一個平臺後即可實現各應用系統的透明跳轉，而且實行統一的使用者資訊管理系統，系統管理員只需維護一套人 員資訊，更改資訊通過平臺介面同步更新至各個應用系統，實現人員系統單次維護全公司同步變更，大大提高工作效率。

二、認識SSO

（一）單點登入的英文名稱為Single Sign-On，簡寫為SSO，它是一個使用者認證的過程，允許使用者一次性進行認證之後，就訪問系統中不同的應用；而不需要訪問每個應用時，都重新輸入密碼。IBM對SSO有一個形象的解釋“單點登入、全網漫遊”。
SSO將一個企業內部所有域中的使用者登入和使用者帳號管理集中到一起，SSO的好處顯而易見：
減少使用者在不同系統中登入耗費的時間，減少使用者登入出錯的可能性
實現安全的同時避免了處理和儲存多套系統使用者的認證資訊
減少了系統管理員增加、刪除使用者和修改使用者許可權的時間
增加了安全性：系統管理員有了更好的方法管理使用者，包括可以通過直接禁止和刪除使用者來取消該使用者對所有系統資源的訪問許可權

（二） SSO的實現機制不盡相同，大體分為Cookie機制和Session機制兩大類。
WebLogic通過Session共享認證資訊。Session是一種伺服器端機制，當客戶端訪問伺服器時，伺服器為客戶端建立一個惟一的 SessionID，以使在整個互動過程中始終保持狀態，而互動的資訊則可由應用自行指定，因此用Session方式實現SSO，不能在多個瀏覽器之間實 現單點登入，但卻可以跨域。
WebSphere通過Cookie記錄認證資訊。Cookie是一種客戶端機制，它儲存的內容主要包括: 名字、值、過期時間、路徑和域，路徑與域合在一起就構成了Cookie的作用範圍，因此用Cookie方式可實現SSO，但域名必須相同。

三、認識cas

（一）CAS 單點登入系統最早由耶魯大學開發。2004年12月，CAS成為JA-SIG中的一個專案。JA-SIG的全稱是Java Architectures Special Interest Group，是在高校中推廣和探討基於Java的開源技術的一個組織。CAS的優點很多，例如設計理念先進、體系結構合理、配置簡單、客戶端支援廣泛、技 術成熟等等。

（二）cas主要特性

1、 開源的、多協議的 SSO 解決方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支援多種認證機制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、 安全策略：使用票據（ Ticket ）來實現支援的認證協議；
4、 支援授權：可以決定哪些服務可以請求和驗證服務票據（ Service Ticket ）；
5、 提供高可用性：通過把認證過的狀態資料儲存在 TicketRegistry 元件中，這些元件有很多支援分散式環境的實現，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支援多種客戶端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

四、cas基本原理

（一）結構體系

從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。CAS Server 負責完成對使用者的認證工作 , 需要獨立部署 , CAS Server 會處理使用者名稱 / 密碼等憑證 (Credentials) 。CAS Client負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的使用者名稱密碼等 Credentials ）。CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。

（二）cas原理和協議---基礎模式

基礎模式 SSO 訪問流程主要有以下步驟：
1. 訪問服務： SSO 客戶端傳送請求訪問應用系統提供的服務資源。
2. 定向認證： SSO 客戶端會重定向使用者請求到 SSO 伺服器。
3. 使用者認證：使用者身份認證。
4. 發放票據： SSO 伺服器會產生一個隨機的 Service Ticket 。
5. 驗證票據： SSO 伺服器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。
6. 傳輸使用者資訊： SSO 伺服器驗證票據通過後，傳輸使用者認證結果資訊給客戶端。
下面是 CAS 最基本的協議過程：

如上圖：

1.應用程式一開始，通常跳過原來的登陸介面，而直接轉向CAS自帶的登入介面。當然也可以在應用程式的主介面上增加一個登入之類的按鈕，來完成跳轉工作。
2.如果使用者喜歡的話，也可以手工直接進入CAS的登入介面，先進行登入，在啟動其他的應用程式。不過這種模式主要用於測試環境。
3.CAS的登入介面處理所謂的“主體認證”。它要求使用者輸入使用者名稱和密碼，就像普通的登入介面一樣。
4.主體認證時，CAS獲取使用者名稱和密碼，然後通過某種認證機制進行認證。通常認證機制是LDAP。
5.為了進行以後的單點登入，CAS向瀏覽器送回一個所謂的“記憶體cookie”。這種cookie並不是真的儲存在記憶體中，而只是瀏覽器一關 閉，cookie就自動過期。這個cookie稱為“ticket-granting cookie”，用來表明使用者已經成功地登入。
6.認證成功後，CAS伺服器建立一個很長的、隨機生成的字串，稱為“Ticket”。隨後，CAS將這個ticket和成功登入的使用者，以及服務聯絡在一起。這個ticket是一次性使用的一種憑證，它只對登入成功的使用者及其服務使用一次。使用過以後立刻失效。
7.主體認證完成後，CAS將使用者的瀏覽器重定向，回到原來的應用。CAS客戶端，在從應用轉向CAS的時候，同時也會記錄原始的URL，因此CAS知道誰在呼叫自己。CAS重定向的時候，將ticket作為一個引數傳遞回去。
8.例如原始應用的網址是http://www.itil.com/，在這個網址上，一開始有如下語句，轉向CAS伺服器的單點登入頁面https: //secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx。
9.CAS完成主體認證後，會使用下面URL進行重定向http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
10.收到ticket之後，應用程式需要驗證ticket。這是通過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是CAS伺服器提供的。
11.CAS通過校驗路徑獲得了ticket之後，通過內部的資料庫對其進行判斷。如果判斷是有效性，則返回一個NetID給應用程式。
12.隨後CAS將ticket作廢，並且在客戶端留下一個cookie。
13.以後其他應用程式就使用這個cookie進行認證（當然通過CAS的客戶端），而不再需要輸入使用者名稱和密碼。
採用.NET 來實現CAS原理的SSO系統，在第一個版本的SSO系統基礎上羅列一些問題，有的已經是第一個版本的SSO系統中採用的方式。

（三）cas原理和協議---代理模式

該模式形式為使用者訪問 App1 ， App1 又依賴於 App2 來獲取一些資訊，如： User -->App1 -->App2 。
這種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麼，為了不影響使用者體驗（過多的重定向導致 User 的 IE 視窗不停地閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理使用者去訪問其它 Web 應用。
代理的前提是需要 CAS Client 擁有使用者的身份資訊 ( 類似憑據 ) 。之前我們提到的 TGC 是使用者持有對自己身份資訊的一種憑據，這裡的 PGT 就是 CAS Client 端持有的對使用者身份資訊的一種憑據。憑藉 TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這裡憑藉 PGT ， Web 應用可以代理使用者去實現後端的認證，而 無需前端使用者的參與 。
下面為代理應用（ helloService ）獲取 PGT 的過程： （注： PGTURL 用於表示一個 Proxy 服務，是一個回撥連結； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關係；）

如上面的 CAS Proxy 圖所示， CAS Client 在基礎協議之上，在驗證 ST 時提供了一個額外的 PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向後端 Web 應用進行認證。
下面是代理認證和提供服務的過程：

如上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。

（四）cas原理和協議---輔助說明

CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 建立 cookie ，在所有應用認證時使用，各應用通過建立各自的 Session 來標識使用者是否已登入。
使用者在一個應用驗證通過後，以後使用者在同一瀏覽器裡訪問此應用時，客戶端應用中的過濾器會在 session 裡讀取到使用者資訊，所以就不會去 CAS Server 認證。如果在此瀏覽器裡訪問別的 web 應用時，客戶端應用中的過濾器在 session 裡讀取不到使用者資訊，就會去 CAS Server 的 login 介面認證，但這時 CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求使用者去登入頁面登入，只是會根據 service 引數生成一個 Ticket ，然後再和 web 應用做一個驗證 ticket 的互動而已。

CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放使用者身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確使用者身份的憑證；
Ø Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務伺服器端；一個特定的服務只能有一個惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 繫結一個使用者的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答資訊由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回撥連結傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之間對映關係的內容表；
Ø Proxy Ticket (PT) ：是應用程式代理使用者身份對目標程式進行訪問的憑證；

其它說明如下：
Ø Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證資訊 (Credentials) ；
Ø Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
Ø Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
Ø KDC( Key Distribution Center ) ---------- 金鑰發放中心；

（四）cas原理和協議---安全性

TGC/PGT 安全性：
對於一個 CAS 使用者來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 使用者訪問 所有 授權資源。 PGT 的角色跟 TGC 是一樣的。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式傳送給終端使用者，因此，要擷取 TGC 難度非常大，從而確保 CAS 的安全性。
TGT 的存活週期預設為 120 分鐘。

ST/PT 安全性：
ST （ Service Ticket ）是通過 Http 傳送的，因此網路中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通過以下幾方面來使 ST 變得更加安全（事實上都是可以配置的）：
1、 ST 只能使用一次
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端快取中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。
2、 ST 在一段時間內失效
CAS 規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。預設有效時間為 5 分鐘。
3、 ST 是基於隨機數生成的
ST 必須足夠隨機，如果 ST 生成規則被猜出， Hacker 就等於繞過 CAS 認證，直接訪問 對應的 服務。

本篇博文結束，下一篇介紹cas客戶端和服務端配置

紙上得來終覺淺，絕知此事要躬行。