統一身份認證（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配置文件。

<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的時序圖

（轉）