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

[size=medium]轉：http://apps.hi.baidu.com/share/detail/2037575

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配置文件。

<bean id="ticketGrantingTicketCookieGenerator"
class="org.springframework.web.util.CookieGenerator">
<property name="cookieSecure" value="true" />
<property name="cookieMaxAge" value="-1" />
<property name="cookieName" value="CASTGC" />
<property name="cookiePath" value="/cas" />
</bean>

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

1. AuthenticationHandler認證處理器
瀏覽項目的web.xml，可以發現如下內容：

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml,
/WEB-INF/deployerConfigContext-acegi.xml
</param-value>
</context-param>
<listener>
<listener-class>
org.jasig.cas.web.init.SafeContextLoaderListener
</listener-class>
</listener>

SafeContextLoaderListener實現了SafeContextListener，它藉助於ContextLoader -Listener裝載Spring DI容器。這樣做的原因是因爲Spring在通過ContextLoaderLitener啓動時可能出現異常，造成整個CAS不能正常啓動，經過SafeContextLoaderListener，則在異常發生時，CAS服務器也可以啓動。

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

<beans>
<bean id="authenticationManager"
class="org.jasig.cas.authentication.AuthenticationManagerImpl">
<property name="credentialsToPrincipalResolvers">
<list>
<bean class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver" />
<bean class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" />
</list>
</property>
<property name="authenticationHandlers">
<list>
<bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" />
<bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
</list>
</property>
</bean>
</beans>

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

AuthenticationManagerImpl負責認證用戶，比如一個admin/admin用戶是否合法就是它來驗證的。AuthenticationManagerImpl對象會藉助於他引用的credentialsToPr -incipalResolvers和authenticationHandlers集合完成用戶的認證工作。Authentication -Handlers負責完成用戶認證，而credentialsToPrincipalResolvers負責構建認證結果。其中，並不是authenticationHandlers的全部集合都參與到用戶認證中，一旦某個AuthenticationHandler成功完成用戶的認證，則認證進程就到此爲止，進而轉到credenti -alsToPrincipalResolvers來構建認證結果。credentialsToPrincipalResolvers的過程也類似於此。

2. CAS的時序圖[/size]