JA-SIG（CAS）學習筆記2

背景知識： 
什麼是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平臺的服務端和客戶端的編程與應用定製等相關內容的進行介紹。