統一身份認證（CAS）簡單說明與設計方案（轉）

1. 單點登錄概述

所謂單點登錄（SSO），只當企業用戶同時訪問多個不同（類型的）應用時，他們只需要提供自身的用戶憑證信息（比如用戶名/密碼）一次，僅僅一次。SSO解決方案（比如，CAS）負責統一認證用戶，如果需要，SSO也可以完成用戶的授權處理。可以看出，當企業用戶在不同的應用間切換時，他們不用再重復地輸入自身的用戶憑證了。在實施SSO後，所用的認證操作都將交給SSO認證中心。現有的SSO解決方案非常多，比如微軟的MSN Passport便是典型的SSO解決方案，各Java EE容器都提供了自身的專有SSO能力。

2. CAS的總體架構

1. CAS簡介

CAS（中央認證服務）是建立在非常開放的協議之上的企業級SSO解決方案。誕生於2001年，在2002年發布了CAS2.0協議，這一新的協議提供了Proxy（代理）能力，此時的CAS2.0支持多層SSO能力。到2005年，CAS成為了JA-SIG旗下的重要子項目。由於CAS2.0版本的可擴展能力不是非常完美，而且他的架構設計也不是很卓越，為了使得CAS能夠適用於更多場合，JA-SIG打算開發出同時遵循CAS1.0和CAS2.0協議的CAS3.X版本。

現在的CAS3全面擁抱Spring技術，比如Spring DI容器和AOP技術、Spring Web MVC、Spring Web Flow、Spring Ldap Template等。

通常，CAS3由兩部分內容構成：CAS3服務器和CAS客戶端。由於CAS2.0協議借助於XML數據結構與客戶進行交互，因此開發者可以使用各種語言編寫的CAS3客戶與服務器進行通信。CAS3服務器采用純Java開發而成，它要求目標運行環境實現了Servlet2.4+規範、提供Java SE 1.4+支持。如果宿主CAS3服務器的目標Java EE容器僅僅實現了Servlet2.3-規範，則在對CAS3服務器進行少量的改造後，CAS3也能運行其中。

運行時，CAS3服務器僅僅是一個簡單的Web應用，使用者只需要將cas.war直接丟到目標Java EE容器後，即完成了CAS3的部署。

2. CAS詞匯概念

TGC(ticket-granting cookie)--------- 受權的票據證明 KDC( Key Distribution Center ) ---------- 密鑰發放中心

Service ticket(ST) --------- 服務票據， 由 KDC 的 TGS 發放。 任何一臺 Workstation 都需要擁有一張有效的 Service Ticket 才能訪問域內部的應用 (Applications) 。 如果能正確接收 Service Ticket ，說明在 CASClient-CASServer 之間的信任關系已經被正確建立起來，通常為一張數字加密的證書 Ticket Granting tieckt(TGT) --------- 票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證信息 ( 準確術語是 Credentials) 。

authentication service (AS) --------- 認證用服務，索取 Crendential ，發放 TGT ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST

3. CAS工作原理

CAS的單點登錄的認證過程，所用應用服務器受到應用請求後，檢查ST和TGT，如果沒有或不對，轉到CAS認證服務器登錄頁面，通過安全認證後得到ST和TGT，再重新定向到相關應用服務器，在回話生命周期之內如果再定向到別的應用，將出示ST和TGT進行認證，註意，取得TGT的過程是通過SSL安全協議的。

如果通俗形象地說就是：相當於用戶要去遊樂場，首先要在門口檢查用戶的身份 ( 即 CHECK 用戶的 ID 和 PASS), 如果用戶通過驗證，遊樂場的門衛 (AS) 即提供給用戶一張門卡 (TGT)。

這張卡片的用處就是告訴遊樂場的各個場所，用戶是通過正門進來，而不是後門偷爬進來的，並且也是獲取進入場所一把鑰匙。

現在用戶有張卡，但是這對用戶來不重要，因為用戶來遊樂場不是為了拿這張卡的而是為了遊覽遊樂項目，這時用戶摩天樓，並想遊玩。

這時摩天輪的服務員 (client) 攔下用戶，向用戶要求摩天輪的 (ST) 票據，用戶說用戶只有一個門卡 (TGT), 那用戶只要把 TGT 放在一旁的票據授權機 (TGS) 上刷一下。

票據授權機 (TGS) 就根據用戶現在所在的摩天輪，給用戶一張摩天輪的票據 (ST), 這樣用戶有了摩天輪的票據，現在用戶可以暢通無阻的進入摩天輪裏遊玩了。

當然如果用戶玩完摩天輪後，想去遊樂園的咖啡廳休息下，那用戶一樣只要帶著那張門卡 (TGT). 到相應的咖啡廳的票據授權機 (TGS) 刷一下，得到咖啡廳的票據 (ST) 就可以進入咖啡廳

當用戶離開遊樂場後，想用這張 TGT 去刷打的回家的費用，對不起，用戶的 TGT 已經過期了，在用戶離開遊樂場那刻開始，用戶的 TGT 就已經銷毀了 。

3. CAS的實現原理

由於CAS是基於Cookie的服務，所以它使用了Spring CookieGenerator來生成相應Cookie，下面的代碼段摘自與CAS服務器的WEB-INF/中的cas-server.xml配置文件。

class=\ork.web.util.CookieGenerator\

一旦用戶登錄到CAS服務器後，可以借助於URL為/cas/logout的地址退出，並且這種logout結果將導致瀏覽器中已存儲的Cookie被銷毀掉，即銷毀CAS與當前用戶間已建立的信任關系（Web SSO會話）。

1. AuthenticationHandler認證處理器

瀏覽項目的web.xml，可以發現如下內容：

contextConfigLocation

/WEB-INF/applicationContext.xml,

/WEB-INF/deployerConfigContext-acegi.xml

org.jasig.cas.web.init.SafeContextLoaderListener

SafeContextLoaderListener實現了SafeContextListener，它借助於ContextLoader -Listener裝載Spring DI容器。這樣做的原因是因為Spring在通過

ContextLoaderLitener啟動時可能出現異常，造成整個CAS不能正常啟動，經過SafeContextLoaderListener，則在異常發生時，CAS服務器也可以啟動。

在deployerConfigContext.xml中，可以看到只定義了一個Bean：

class=\

SimpleTestUsernamePasswordAuthenticationHandler的作用是如果用戶名與密碼輸入一樣，則通過系統認證。這個是開發過程中常用的一個handler，但是在開發完畢後應該除去。

AuthenticationManagerImpl負責認證用戶，比如一個admin/admin用戶是否合法就是它來驗證的。AuthenticationManagerImpl對象會借助於他引用的credentialsToPr -incipalResolvers和authenticationHandlers集合完成用戶的認證工作。Authentication -Handlers負責完成用戶認證，而

credentialsToPrincipalResolvers負責構建認證結果。其中，並不是authenticationHandlers的全部集合都參與到用戶認證中，一旦某個AuthenticationHandler成功完成用戶的認證，則認證進程就到此為止，進而轉到credenti -alsToPrincipalResolvers來構建認證結果。credentialsToPrincipalResolvers的過程也類似於此。

2. CAS的時序圖

[轉]統一身份認證(CAS)簡單說明與設計方案