背景知識：
什麼是SSO（Single Sign On）單點登錄：
所謂單點登錄是指基於用戶/會話認證的一個過程，用戶只需一次性提供憑證（僅一次登錄），就可以訪問多個應用。
目前單點登錄主要基於Web的多種應用程序，即通過瀏覽器實現對多個B/S架構應用的統一賬戶認證。
JA-SIG（CAS）的設計願景：
簡單的說，CAS（Central Authentication Service – 中心認證服務）的目的就是使分佈在一個企業內部各個不同異構系統的認證工作集中在一起，通過一個公用的認證系統統一管理和驗證用戶的身份。在CAS上認證的用戶將獲得CAS頒發的一個證書，使用這個證書，用戶可以在承認CAS證書的各個系統上自由穿梭訪問，不需要再次的登錄認證。打個比方：對於加入歐盟的國家而言，在他們國家中的公民可以憑藉着自己的身份證，在整個歐洲旅行，不用簽證。對於企業內部系統而言，CAS就是這個頒發歐盟認證的系統，其它系統都是加入歐盟的國家，它們要共同遵守和承認CAS的認證規則。
因此CAS的設計願景就是：
1。實現一個易用的、能跨不同Web應用的單點登錄認證中心；
2。實現統一的用戶身份和密鑰管理，減少多套密碼系統造成的管理成本和安全漏洞；
3。降低認證模塊在IT系統設計中的耦合度，提供更好的SOA設計和更彈性的安全策略
CAS1.0服務架構實現：
傳統的用戶認證流程
我們以A公司的員工日誌管理系統爲例，如下圖：
![]()
使用CAS後的用戶認證流程
![]()
示意圖中，CAS相關部分被標示爲藍色。在這個流程中，員工AT向日志系統請求進入主頁面，他的瀏覽器發出的HTTP請求被嵌入在日誌系統中的CAS客戶端（HTTP過濾器）攔截，並判斷該請求是否帶有CAS的證書；如果沒有，員工AT將被定位到CAS的統一用戶登錄界面進行登錄認證，成功後，CAS將自動引導AT返回日誌系統的主頁面。
CAS的程序邏輯實現
要完成上述的認證業務，CAS需要一個認證中心服務器CAS -Server和嵌入在不同業務系統方的認證客戶端CAS-Client的協同。
在CAS1.0協議中，CAS-Server提供的三個驗證服務接口（web服務URL）：
1. 用戶登錄URL，形如 https://casserver/cas/servlet/login
2. 用戶憑證校驗URL，形如 https://casserver/cas/servlet/validate
3. 用戶登出URL，形如 https://casserver/cas/servlet/logout
在CAS-Client端，CAS提供了多樣化的語言支持，其中用於java的是一個casclient.jar包。目前的版本爲2.1.1，其中提供了三種形式的憑證校驗：
1. 用於Java Servlets的Filter — edu.yale.its.tp.cas.client.filter.CASFilter
2. 用於JSP頁面的CAS Tag Library
3. 通用Java API Object — ServiceTicketValidator / ProxyTicketValidator
通常，企業應用程序基於瀏覽器的B/S模式，這種情況下，系統的用戶憑證（一個由CAS服務器生成的唯一 id號，也稱之爲ticket）藉助cookie和URL參數方式實現；在B/S環境中，大多情況下，我們只需要配置CAS Filter或者使用CAS Tag Library就可以輕鬆實現的驗證客戶端。
如果應用是以普通的C/S模式運行，則需要應用程序自己來維護這個ticket在上下文環境中的傳輸和保存了。這時候就需要手工調用ServiceTicketValidator / ProxyTicketValidator對象的方法，向CAS 服務器提交認證，並獲取認證結果進行相應的處理。
CAS服務的具體實現
環境假設：用戶User要訪問業務系統Biz；Biz系統部署在bizserver上；CAS的系統搭建在服務器casserver上。
![]( "點擊查看原始大小圖片")
圖例說明：
Step1: 用戶第一次訪問Biz系統主頁http://bizserver/index.jsp ;部署在Biz系統上的CASFilter發現用戶尚未登錄，將用戶重定向的CAS登錄界面 https://casserver/cas/servlet/login?service=http://bizserver/index.jsp ，同時在重定向的URL上用service參數將用戶的目標地址傳給CAS服務器。
Step2:用戶在CAS的登錄頁上輸入用戶名密碼登錄，CAS服務器認證通過後，生成一個ticket，並帶在目標地址的尾部返回客戶端的瀏覽器redirect：http://bizserver/index.jsp?ticket=casticket.
Step3:客戶端瀏覽器獲得CAS服務器的認證應答，取得憑證ticket後，使用重定向的鏈接http://bizserver/index.jsp?ticket=casticket訪問Biz服務
Step4: BizServer上的CASFilter再次過濾訪問請求，並獲得ticket憑證。Filter將使用該憑證通過URL https://casserver/cas/servlet/validate?service= http://bizserver/index.jsp &ticket=casticket 向CAS認證中心確認對應的服務請求和憑證是否有效。根據CAS服務器返回的結果，如果憑證有效，則CASFilter允許用戶進入http://bizserver/index.jsp 所指向的頁面；否則，再次重定向到https://casserver/cas/servlet/login?service=http://bizserver/index.jsp 上要求用戶進行認證。
CAS2.0服務架構實現：
CAS2.0的協議主要是針對web應用的SSO功能增強的協議，它在1.0協議基礎上擴展了Proxy Authentication（代理認證）能力。那麼什麼是Proxy Authentication呢？！
代理認證Proxy Authentication
假設有一下這樣的應用場景：用戶AT早晨來到公司，他的第一件事就是進入公司的Portal系統瀏覽一天的新諮詢，如股票信息、天氣情況、業界新聞。他通過CAS的身份認證登錄了門戶系統，看到了他訂製的信息。之後，他要訪問portal中的郵件信息，看看有沒有新的郵件。這時候Portal系統必須訪問他的IMAP服務器，這需要他的私人密碼。我們知道Portal是通過CAS對AT進行認證的，因此Portal上沒有AT的個人密碼信息。這時，我們發現，Portal需要代表AT的身份向IMAP服務器提交身份認證，而這正是Proxy Authentication的作用。
CAS2.0系統架構中的角色
![]()
CAS2.0系統中的用到的憑證（ticket）
![]()
以上對於CAS2.0協議中用到的5種ticket的說明，乍看起來也許會讓你雲裏霧裏的。沒關係，下面我們就來詳細闡述這5種憑證在實際認證流程中的作用。在闡述具體流程前，我們要先關注一下2.0協議中對客戶端配置的需求.
CAS2.0的客戶端配置
在2.0協議中，CAS-Server端的配置與1.0基本一致。但在客戶端上，多增加了一個call back URL，該URL用來提供server端向client端傳輸PGT時使用。因此，除了要配置edu.yale.its.tp.cas.client.filter.CASFilter作爲認證過濾器外，還要配置edu.yale.its.tp.cas.proxy.ProxyTicketReceptor這個servlet，作爲server回傳PGT的call back URL，如下：
![]()
CAS2.0代理認證流程
以下的流程圖模擬上述的用戶AT通過Portal向他的IMAP郵件服務器請求電子郵件的認證過程。在該過程中，充當Service和Proxy兩個角色的Portal使用CAS Filter對訪問其自身的用戶進行CAS認證；同時Portal要使用ProxyTicketReceptor servlet接收來自CAS server的PGT信息，並使用ProxyTicketValidator對象向CAS獲取訪問IMAP服務器的Proxy Ticket憑證；最終從IMAP服務器上獲取AT用戶的mail信息。同樣的，這裏的IMAP服務器也要接受並認可CAS對其用戶的認證管理，同時它自己也成爲二級Proxy，在有需要的情況下，一樣可以向它的back-end Service發起Proxy Authentication代理認證請求……
![]()
其中藍色線表示HTTP或HTTPS的請求；紅色線表示應答；黑色線表示來自CAS server端的回調操作。
到此，本章節對JA-SIG（CAS）的整體功能和身份認證業務架構進行初步的講解，在後續的章節中，我們將對CAS平臺的服務端和客戶端的編程與應用定製等相關內容的進行介紹。
什麼是SSO（Single Sign On）單點登錄：
所謂單點登錄是指基於用戶/會話認證的一個過程，用戶只需一次性提供憑證（僅一次登錄），就可以訪問多個應用。
目前單點登錄主要基於Web的多種應用程序，即通過瀏覽器實現對多個B/S架構應用的統一賬戶認證。
JA-SIG（CAS）的設計願景：
簡單的說，CAS（Central Authentication Service – 中心認證服務）的目的就是使分佈在一個企業內部各個不同異構系統的認證工作集中在一起，通過一個公用的認證系統統一管理和驗證用戶的身份。在CAS上認證的用戶將獲得CAS頒發的一個證書，使用這個證書，用戶可以在承認CAS證書的各個系統上自由穿梭訪問，不需要再次的登錄認證。打個比方：對於加入歐盟的國家而言，在他們國家中的公民可以憑藉着自己的身份證，在整個歐洲旅行，不用簽證。對於企業內部系統而言，CAS就是這個頒發歐盟認證的系統，其它系統都是加入歐盟的國家，它們要共同遵守和承認CAS的認證規則。
因此CAS的設計願景就是：
1。實現一個易用的、能跨不同Web應用的單點登錄認證中心；
2。實現統一的用戶身份和密鑰管理，減少多套密碼系統造成的管理成本和安全漏洞；
3。降低認證模塊在IT系統設計中的耦合度，提供更好的SOA設計和更彈性的安全策略
CAS1.0服務架構實現：
傳統的用戶認證流程
我們以A公司的員工日誌管理系統爲例，如下圖：
使用CAS後的用戶認證流程
示意圖中，CAS相關部分被標示爲藍色。在這個流程中，員工AT向日志系統請求進入主頁面，他的瀏覽器發出的HTTP請求被嵌入在日誌系統中的CAS客戶端（HTTP過濾器）攔截，並判斷該請求是否帶有CAS的證書；如果沒有，員工AT將被定位到CAS的統一用戶登錄界面進行登錄認證，成功後，CAS將自動引導AT返回日誌系統的主頁面。
CAS的程序邏輯實現
要完成上述的認證業務，CAS需要一個認證中心服務器CAS -Server和嵌入在不同業務系統方的認證客戶端CAS-Client的協同。
在CAS1.0協議中，CAS-Server提供的三個驗證服務接口（web服務URL）：
1. 用戶登錄URL，形如 https://casserver/cas/servlet/login
2. 用戶憑證校驗URL，形如 https://casserver/cas/servlet/validate
3. 用戶登出URL，形如 https://casserver/cas/servlet/logout
在CAS-Client端，CAS提供了多樣化的語言支持，其中用於java的是一個casclient.jar包。目前的版本爲2.1.1，其中提供了三種形式的憑證校驗：
1. 用於Java Servlets的Filter — edu.yale.its.tp.cas.client.filter.CASFilter
2. 用於JSP頁面的CAS Tag Library
3. 通用Java API Object — ServiceTicketValidator / ProxyTicketValidator
通常，企業應用程序基於瀏覽器的B/S模式，這種情況下，系統的用戶憑證（一個由CAS服務器生成的唯一 id號，也稱之爲ticket）藉助cookie和URL參數方式實現；在B/S環境中，大多情況下，我們只需要配置CAS Filter或者使用CAS Tag Library就可以輕鬆實現的驗證客戶端。
如果應用是以普通的C/S模式運行，則需要應用程序自己來維護這個ticket在上下文環境中的傳輸和保存了。這時候就需要手工調用ServiceTicketValidator / ProxyTicketValidator對象的方法，向CAS 服務器提交認證，並獲取認證結果進行相應的處理。
CAS服務的具體實現
環境假設：用戶User要訪問業務系統Biz；Biz系統部署在bizserver上；CAS的系統搭建在服務器casserver上。
圖例說明：
Step1: 用戶第一次訪問Biz系統主頁http://bizserver/index.jsp ;部署在Biz系統上的CASFilter發現用戶尚未登錄，將用戶重定向的CAS登錄界面 https://casserver/cas/servlet/login?service=http://bizserver/index.jsp ，同時在重定向的URL上用service參數將用戶的目標地址傳給CAS服務器。
Step2:用戶在CAS的登錄頁上輸入用戶名密碼登錄，CAS服務器認證通過後，生成一個ticket，並帶在目標地址的尾部返回客戶端的瀏覽器redirect：http://bizserver/index.jsp?ticket=casticket.
Step3:客戶端瀏覽器獲得CAS服務器的認證應答，取得憑證ticket後，使用重定向的鏈接http://bizserver/index.jsp?ticket=casticket訪問Biz服務
Step4: BizServer上的CASFilter再次過濾訪問請求，並獲得ticket憑證。Filter將使用該憑證通過URL https://casserver/cas/servlet/validate?service= http://bizserver/index.jsp &ticket=casticket 向CAS認證中心確認對應的服務請求和憑證是否有效。根據CAS服務器返回的結果，如果憑證有效，則CASFilter允許用戶進入http://bizserver/index.jsp 所指向的頁面；否則，再次重定向到https://casserver/cas/servlet/login?service=http://bizserver/index.jsp 上要求用戶進行認證。
CAS2.0服務架構實現：
CAS2.0的協議主要是針對web應用的SSO功能增強的協議，它在1.0協議基礎上擴展了Proxy Authentication（代理認證）能力。那麼什麼是Proxy Authentication呢？！
代理認證Proxy Authentication
假設有一下這樣的應用場景：用戶AT早晨來到公司，他的第一件事就是進入公司的Portal系統瀏覽一天的新諮詢，如股票信息、天氣情況、業界新聞。他通過CAS的身份認證登錄了門戶系統，看到了他訂製的信息。之後，他要訪問portal中的郵件信息，看看有沒有新的郵件。這時候Portal系統必須訪問他的IMAP服務器，這需要他的私人密碼。我們知道Portal是通過CAS對AT進行認證的，因此Portal上沒有AT的個人密碼信息。這時，我們發現，Portal需要代表AT的身份向IMAP服務器提交身份認證，而這正是Proxy Authentication的作用。
CAS2.0系統架構中的角色
CAS2.0系統中的用到的憑證（ticket）
以上對於CAS2.0協議中用到的5種ticket的說明，乍看起來也許會讓你雲裏霧裏的。沒關係，下面我們就來詳細闡述這5種憑證在實際認證流程中的作用。在闡述具體流程前，我們要先關注一下2.0協議中對客戶端配置的需求.
CAS2.0的客戶端配置
在2.0協議中，CAS-Server端的配置與1.0基本一致。但在客戶端上，多增加了一個call back URL，該URL用來提供server端向client端傳輸PGT時使用。因此，除了要配置edu.yale.its.tp.cas.client.filter.CASFilter作爲認證過濾器外，還要配置edu.yale.its.tp.cas.proxy.ProxyTicketReceptor這個servlet，作爲server回傳PGT的call back URL，如下：
CAS2.0代理認證流程
以下的流程圖模擬上述的用戶AT通過Portal向他的IMAP郵件服務器請求電子郵件的認證過程。在該過程中，充當Service和Proxy兩個角色的Portal使用CAS Filter對訪問其自身的用戶進行CAS認證；同時Portal要使用ProxyTicketReceptor servlet接收來自CAS server的PGT信息，並使用ProxyTicketValidator對象向CAS獲取訪問IMAP服務器的Proxy Ticket憑證；最終從IMAP服務器上獲取AT用戶的mail信息。同樣的，這裏的IMAP服務器也要接受並認可CAS對其用戶的認證管理，同時它自己也成爲二級Proxy，在有需要的情況下，一樣可以向它的back-end Service發起Proxy Authentication代理認證請求……
其中藍色線表示HTTP或HTTPS的請求；紅色線表示應答；黑色線表示來自CAS server端的回調操作。
到此，本章節對JA-SIG（CAS）的整體功能和身份認證業務架構進行初步的講解，在後續的章節中，我們將對CAS平臺的服務端和客戶端的編程與應用定製等相關內容的進行介紹。
