一次 工作過程 true let 壓縮包 app 再次 三方 提示

1. CAS 簡介

1.1. What is CAS ？

CAS （ Central Authentication Service ） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO ）。

CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。

1.2. 主要特性

1、 開源的、多協議的 SSO 解決方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。

2、 支持多種認證機制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates等；

3、 安全策略：使用票據（ Ticket ）來實現支持的認證協議；

4、 支持授權：可以決定哪些服務可以請求和驗證服務票據（ Service Ticket ）；

5、 提供高可用性：通過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有很多支持分布式環境的實現，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；

6、 支持多種客戶端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

2. SSO 單點登錄原理

本文內容主要針對 Web SSO 。

2.1. 什麽是SSO

單點登錄（ Single Sign-On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，用戶只需要 登錄一次 就可以訪問所有相互信任的應用系統。

2.2. SSO 原理

2.2.1. SSO 體系中的角色

一般 SSO 體系主要角色有三種：

1、 User （多個）

2、 Web 應用（多個）

3、 SSO 認證中心（ 1 個 ）

2.2.2. SSO 實現模式的原則

SSO 實現模式一般包括以下三個原則：

1、 所有的認證登錄都在 SSO 認證中心進行；

2、 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問用戶究竟是不是已通過認證的用戶；

3、 SSO 認證中心和所有的 Web 應用建立一種信任關系，也就是說 web 應用必須信任認證中心。（單點信任）

2.2.3. SSO 主要實現方式

SSO 的主要實現方式有：

1、 共享 cookies

基於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌傳遞問題；另外，關於跨域問題，雖然 cookies 本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。

缺點：不靈活而且有不少安全隱患，已經被拋棄。

2、 Broker-based( 基於經紀人 )

這種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人給被用於進一步請求的電子身份存取。中央數據庫的使用減少了管理的代價，並為認證提供一個公共和獨立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為默認的安全認證服務集成進操作系統。

3、 Agent-based （基於代理人）

在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在服務器上面，在服務器的認證系統和客戶端認證方法之間充當一個 " 翻譯 " 。例如 SSH 等。

4、 Token-based

例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件服務器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。

5、 基於網關

6、 基於 SAML

SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批準為 SSO 的執行標準 。開源組織 OpenSAML 實現了 SAML 規範。

3. CAS 的基本原理

3.1. 結構體系

從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。

3.1.1. CAS Server

CAS Server 負責完成對用戶的認證工作 , 需要獨立部署 , CAS Server 會處理用戶名 / 密碼等憑證(Credentials) 。

3.1.2. CAS Client

負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等 Credentials ）。

CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。

3.2. CAS 原理和協議

3.2.1. 基礎模式

基礎模式 SSO 訪問流程主要有以下步驟：

1. 訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。

2. 定向認證： SSO 客戶端會重定向用戶請求到 SSO 服務器。

3. 用戶認證：用戶身份認證。

4. 發放票據： SSO 服務器會產生一個隨機的 Service Ticket 。

5. 驗證票據： SSO 服務器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。

6. 傳輸用戶信息： SSO 服務器驗證票據通過後，傳輸用戶認證結果信息給客戶端。

下面是 CAS 最基本的協議過程：

基礎協議圖

如上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經過認證的；於是 CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ），並傳遞 Service （要訪問的目的資源地址）。 Step 3 是用戶認證過程，如果用戶提供了正確的 Credentials ， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並緩存以待將來驗證，並且重定向用戶到 Service 所在地址（附帶剛才產生的 Service Ticket ） , 並為客戶端瀏覽器設置一個 Ticket Granted Cookie （ TGC ） ； CAS Client在拿到 Service 和新產生的 Ticket 過後，在 Step 5 和 Step6 中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。

在該協議中，所有與 CAS Server 的交互均采用 SSL 協議，以確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向 的過程。但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的（使用 HttpsURLConnection ）。

CAS 請求認證時序圖如下：

3.2.1. CAS 如何實現 SSO

當用戶訪問另一個應用的服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：

1) 如果 User 持有 TGC 且其還沒失效，那麽就走基礎協議圖的 Step4 ，達到了 SSO 的效果；

2) 如果 TGC 失效，那麽用戶還是要重新認證 ( 走基礎協議圖的 Step3) 。

3.2.2. CAS 代理模式

該模式形式為用戶訪問 App1 ， App1 又依賴於 App2 來獲取一些信息，如： User -->App1 -->App2 。

這種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麽，為了不影響用戶體驗（過多的重定向導致 User 的 IE 窗口不停地閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應用。

代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據 ) 。之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據，這裏的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據。憑借TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這裏憑借 PGT ， Web應用可以代理用戶去實現後端的認證，而 無需前端用戶的參與 。

下面為代理應用（ helloService ）獲取 PGT 的過程： （註： PGTURL 用於表示一個 Proxy 服務，是一個回調鏈接； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關系；）

如上面的 CAS Proxy 圖所示， CAS Client 在基礎協議之上，在驗證 ST 時提供了一個額外的PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。

CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向後端 Web 應用進行認證。

下面是代理認證和提供服務的過程：

如上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是Service Ticket 。

3.2.3. 輔助說明

CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 創建 cookie，在所有應用認證時使用，各應用通過創建各自的 Session 來標識用戶是否已登錄。

用戶在一個應用驗證通過後，以後用戶在同一瀏覽器裏訪問此應用時，客戶端應用中的過濾器會在 session 裏讀取到用戶信息，所以就不會去 CAS Server 認證。如果在此瀏覽器裏訪問別的 web 應用時，客戶端應用中的過濾器在 session 裏讀取不到用戶信息，就會去 CAS Server 的 login 接口認證，但這時CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求用戶去登錄頁面登錄，只是會根據 service 參數生成一個 Ticket ，然後再和 web 應用做一個驗證 ticket 的交互而已。

3.3. 術語解釋

CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。

• Ticket-granting cookie(TGC) ：存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確用戶身份的憑證；
• Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務服務器端；一個特定的服務只能有一個惟一的 ST ；
• Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
• Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回調鏈接傳給 Web應用。 Web 應用負責維護 PGTIOU 與 PGT 之間映射關系的內容表；
• Proxy Ticket (PT) ：是應用程序代理用戶身份對目標程序進行訪問的憑證；

其它說明如下：

• Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證信息 (Credentials) ；
• Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
• Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
• KDC( Key Distribution Center ) ---------- 密鑰發放中心；

4. CAS 安全性

CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。

4.1. TGC/PGT 安全性

對於一個 CAS 用戶來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 用戶訪問 所有 授權資源。 PGT 的角色跟 TGC 是一樣的。

從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。

TGT 的存活周期默認為 120 分鐘。

4.2. ST/PT 安全性

ST （ Service Ticket ）是通過 Http 傳送的，因此網絡中的其他人可以 Sniffer 到其他人的 Ticket。 CAS 通過以下幾方面來使 ST 變得更加安全（事實上都是可以配置的）：

1、 ST 只能使用一次

CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端緩存中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。

2、 ST 在一段時間內失效

CAS 規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。默認有效時間為 5 分鐘。

3、 ST 是基於隨機數生成的

ST 必須足夠隨機，如果 ST 生成規則被猜出， Hacker 就等於繞過 CAS 認證，直接訪問 對應的服務。

5. 參考資料

1、 https://wiki.jasig.org/display/CASUM/Introduction

2、 http://www.jasig.org/cas/protocol/

3、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

4、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

5、 http://baike.baidu.com/view/190743.htm

---

CAS單點登錄(SSO)完整教程(2012-02-01更新)

一、教程說明

前言

• 教程目的：從頭到尾細細道來單點登錄服務器及客戶端應用的每個步驟
• 單點登錄（SSO）：請看百科解釋猛擊這裏打開
• 本教程使用的SSO服務器是Yelu大學研發的CAS(Central Authentication Server)，
  官網：http://www.jasig.org/cas

本教程環境：

• Tomcat6.0.29
• JDK6
• CAS Server版本：cas-server-3.4.3.1、cas-server-3.4.10
• CAS Client版本：cas-client-3.1.12、cas-client-3.2.1
• 教程撰寫日期：2010-11-05(第一版)、2011-11-05(一年後更新)、2012-02-01(異常處理)
• 教程作者：咖啡兔

二、創建證書

啰嗦幾句：證書是單點登錄認證系統中很重要的一把鑰匙，客戶端於服務器的交互安全靠的就是證書；本教程由於是演示所以就自己用JDK自帶的keytool工具生成證書；如果以後真正在產品環境中使用肯定要去證書提供商去購買，證書認證一般都是由VeriSign認證，中文官方網站：http://www.verisign.com/cn/

用JDK自帶的keytool工具生成證書：

keytool -genkey -alias wsria -keyalg RSA -keystore d:/keys/wsriakey

無圖不給力，有圖有真相：

具體的輸入項圖片中都有說明，有一點我要解釋一下；在輸入完密碼後提示輸入域名是我輸入的是sso.wsria.com，其實這個域名是不存在的，但是我為了演示所以虛擬了這個域名，技巧在於修改

C:\Windows\System32\drivers\etc\hosts

添加內容如下：

127.0.0.1  sso.wsria.com

這樣在訪問sso.wsria.com的時候其實是訪問的127.0.0.1也就是本機

嚴重提醒：提示輸入域名的時候不能輸入IP地址

三、導出證書

D:\keys>keytool -export -file d:/keys/wsria.crt -alias wsria -keystore d:/keys/wsriakey

特別提示：如果提示：

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

那麽請輸入密碼：changeit

來點顏色：

至此導出證書完成，可以分發給應用的JDK使用了，接下來講解客戶端的JVM怎麽導入證書。

四、為客戶端的JVM導入證書

keytool -import -keystore D:\tools\jdk\1.6\jdk1.6.0_20\jre\lib\security\cacerts -file D:/keys/wsria.crt -alias wsria

來點顏色瞧瞧：

特別說明

D:\tools\jdk\1.6\jdk1.6.0_20\jre\lib\security -- 是jre的目錄；密碼還是剛剛輸入的密碼。至此證書的創建、導出、導入到客戶端JVM都已完成，下面開始使用證書到Web服務器中，本教程使用tomcat。

五、應用證書到Web服務器-Tomcat

說是應用起始做的事情就是啟用Web服務器(Tomcat)的SSL，也就是HTTPS加密協議，為什麽加密我就不用啰嗦了吧……準備好一個幹凈的tomcat，本教程使用的apache-tomcat-6.0.29打開tomcat目錄的conf/server.xml文件，開啟83和87行的註釋代碼，並設置keystoreFile、keystorePass修改結果如下：

?

1 2	< connector port = "8443" protocol = "HTTP/1.1" sslenabled = "true" maxthreads = "150" scheme = "https" secure = "true" clientauth = "false" sslprotocol = "TLS" keystorefile = "D:/keys/wsriakey" keystorepass = "wsria.com" > connector >

參數說明：

• keystoreFile：在第一步創建的key存放位置
• keystorePass：創建證書時的密碼

好了，到此Tomcat的SSL啟用完成，現在你可以啟動tomcat試一下了，例如本教程輸入地址：https://sso.wsria.com:8443/打開的是：

好的，那麽我們點擊“繼續瀏覽此網站(不推薦)。現在進入Tomcat目錄了吧，如果是那麽你又向成功邁進了一步。

OK，接下來要配置CAS服務器了。

六、CAS服務器初體驗

• CAS服務端下載：http://www.jasig.org/cas/download

• 下載完成後將cas-server-3.4.3.1.zip解壓，解壓cas-server-3.4.3/modules/cas-server-webapp-3.4.3.1.war，改名為cas，然後復制cas目錄到你的tomcat/webapp目錄下

• 現在可以訪問CAS應用了，當然要使用HTTPS加密協議訪問，例如本教程地址：https://sso.wsria.com:8443/cas/login ，現在打開了CAS服務器的頁面輸入admin/admin點擊登錄（CAS默認的驗證規則只要用戶名和密碼相同就通過）所以如果你看到下面的這張圖片你就成功了

你成功了嗎？如果沒有成功請再檢查以上步驟！

2011-11-05更新說明

使用Maven構建：

使用cmd或者shell進入cas-server-3.4.10目錄，運行：

?

1	mvn package -pl cas-server-webapp,cas-server-support-jdbc

意思是只需要構建cas-server-webapp和cas-server-support-jdbc，如果需要其他的請根據文件夾名稱設置或者構建全部模塊，打包全部模塊命令：mvn package 即可。打包過程中會從網絡下載需要的jar包，請耐心等待；如果在~/.m2/settings.xml中定義了mirror代理 ，那麽請把隨便修改一個字符，否則下載jar包會失敗！

打包完成後就可以從cas-server-webapp/target/cas.war復制到你的tomcat/webapp中；或者直接復制cas-server-webapp/target/cas-server-webapp-3.4.10目錄到tomcat/webapp目錄下，其他步驟和上面一樣。

七、CAS服務器深入配置

上面的初體驗僅僅是簡單的身份驗證，實際應用中肯定是要讀取數據庫的數據，下面我們來進一步配置CAS服務器怎麽讀取數據庫的信息進行身份驗證。首先打開

tomcat/webapp/cas/WEB-INF/deployerConfigContext.xml

配置的地方如下：

找到第92行處，註釋掉：SimpleTestUsernamePasswordAuthenticationHandler這個驗證Handler，這個是比較簡單的，只是判斷用戶名和密碼相同即可通過，這個肯定不能在實際應用中使用，棄用！

註釋掉92行後在下面添加下面的代碼：

?

1 2 3 4 5

< bean class = "org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"> < property name = "dataSource" ref = "dataSource" > property > < property name = "sql" value = "select password from t_admin_user where login_name=?" > property > < property name = "passwordEncoder" ref = "MD5PasswordEncoder" > property > bean >

在文件的末尾之前加入如下代碼：

?

1 2 3 4 5 6 7 8 9 10 11 12

< bean id = "dataSource" class = "org.springframework.jdbc.datasource.DriverManagerDataSource" > < property name = "driverClassName" >< value >com.mysql.jdbc.Driver value > property > < property name = "url" >< value >jdbc:mysql:///wsriademo value > property > < property name = "username" >< value >root value > property > < property name = "password" >< value >root value > property > bean > < bean id = "MD5PasswordEncoder" class = "org.jasig.cas.authentication.handler.DefaultPasswordEncoder" > < constructor-arg index = "0" > < value >MD5 value > constructor-arg > bean >

復制cas-server-3.4.3.1\modules\cas-server-support-jdbc-3.4.3.1.jar和mysql驅動jar包到tomcat/webapp/cas/WEB-INF/lib目錄

配置解釋：

• QueryDatabaseAuthenticationHandler，是cas-server-support-jdbc提供的查詢接口其中一個，QueryDatabaseAuthenticationHandler是通過配置一個 SQL 語句查出密碼，與所給密碼匹配

• dataSource,我就不用解釋了吧，就是使用JDBC查詢時的數據源

• sql，語句就是查詢哪一張表，本例根據t_admin_user表的login_name字段查詢密碼，CAS會匹配用戶輸入的密碼，如果匹配則通過；下面是t_admin_user的表結構：

?

1 2 3 4 5 6 7 8

create table t_admin_user ( id bigint not null auto_increment, email varchar (255), login_name varchar (255) not null unique , name varchar (255), password varchar (255), primary key (id) ) ENGINE=InnoDB;

• passwordEncoder，這個就算是自己加的鹽巴了，意思很明顯就是處理密碼的加密，看你的應用中數據庫保存的是明碼還是加密過的，比如本例是使用MD5加密的，所以配置了MD5PasswordEncoder這個Handler，cas內置了MD5的功能所以只需要配置一下就可以了；如果在實際應用中使用的是公司自己的加密算法那麽就需要自己寫一個Handler來處理密碼，實現方式也比較簡單，創建一個類繼承org.jasig.cas.authentication.handler.PasswordEncoder然後在encode方法中加密用戶輸入的密碼然後返回即可

八、配置CAS客戶端

添加cas-client的jar包，有兩種方式：

傳統型

下載cas-client，地址：http://www.ja-sig.org/downloads/cas-clients/，然後解壓cas-client-3.1.12.zip，在modules文件夾中有需要的jar包，請根據自己的項目情況選擇使用

2011-11-05更新：

用maven打包server的方式一樣，在cas-client-3.2.1目錄中運行命令：

?

1	mvn package -pl cas-client-core -DskipTests= true

然後從target目錄中復制cas-client-core-3.2.1.jar到應用的WEB-INF/lib目錄中

Maven型

?

1 2 3 4 5

< dependency > < groupid >org.jasig.cas.client groupid > < artifactid >cas-client-core artifactid > < version >3.1.12 version > dependency >

設置filter

編輯web.xml，然後粘貼下面的代碼：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

< listener > < listener-class >org.jasig.cas.client.session.SingleSignOutHttpSessionListener listener-class > listener > < filter > < filter-name >CAS Single Sign Out Filter filter-name > < filter-class >org.jasig.cas.client.session.SingleSignOutFilter filter-class > filter > < filter-mapping > < filter-name >CAS Single Sign Out Filter filter-name > < url-pattern >/* url-pattern > filter-mapping > < filter > < filter-name >CASFilter filter-name > < filter-class >org.jasig.cas.client.authentication.AuthenticationFilter filter-class > < init-param > < param-name >casServerLoginUrl param-name > < param-value >https://sso.wsria.com:8443/cas/login param-value > init-param > < init-param > < param-name >serverName param-name > < param-value >http://localhost:10000 param-value > init-param > filter > < filter-mapping > < filter-name >CASFilter filter-name > < url-pattern >/* url-pattern > filter-mapping > < filter > < filter-name >CAS Validation Filter filter-name > < filter-class > org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter filter-class > < init-param > < param-name >casServerUrlPrefix param-name > < param-value >https://sso.wsria.com:8443/cas param-value > init-param > < init-param > < param-name >serverName param-name > < param-value >http://localhost:10000 param-value > init-param > filter > < filter-mapping > < filter-name >CAS Validation Filter filter-name > < url-pattern >/* url-pattern > filter-mapping > < filter > < filter-name >CAS HttpServletRequest Wrapper Filter filter-name > < filter-class > org.jasig.cas.client.util.HttpServletRequestWrapperFilter filter-class > filter > < filter-mapping > < filter-name >CAS HttpServletRequest Wrapper Filter filter-name > < url-pattern >/* url-pattern > filter-mapping > < filter > < filter-name >CAS Assertion Thread Local Filter filter-name > < filter-class >org.jasig.cas.client.util.AssertionThreadLocalFilter filter-class > filter > < filter-mapping > < filter-name >CAS Assertion Thread Local Filter filter-name > < url-pattern >/* url-pattern > filter-mapping > < filter > < display-name >AutoSetUserAdapterFilter display-name > < filter-name >AutoSetUserAdapterFilter filter-name > < filter-class >com.wsria.demo.filter.AutoSetUserAdapterFilter filter-class > filter > < filter-mapping > < filter-name >AutoSetUserAdapterFilter filter-name > < url-pattern >/* url-pattern > filter-mapping >

每個Filter的功能我就不多說了，都有註釋的，關鍵要解釋一下AutoSetUserAdapterFilter的作用和原理.查看完整的web.xml請 猛擊這裏

利用AutoSetUserAdapterFilter自動根據CAS信息設置Session的用戶信息

先看一下這個AutoSetUserAdapterFilter.java的源碼

好的，如果你是老程序員應該很快就清楚Filter的目的，如果不太懂我再講解一下；主要是通過CAS的const_cas_assertion獲取從CAS服務器登陸的用戶名，然後再根據系統內部的用戶工具（UserUtil.java）來判斷是否已經登錄過，如果沒有登錄根據登錄名從數據庫查詢用戶信息，最後使用設置把用戶信息設置到當前session中。這樣就把用戶信息保存到了Sessino中，我們就可以通過UserUtil工具來獲取當前登錄的用戶了，我在實例項目中也加入了此功能演示，請看代碼：main.jsp的第44行處

補充一下：

如果是為一個老項目添加單點登錄功能，那麽基本不需要其他的修改，設置好上面的filter即可；當然最好獲取用戶信息的地方都調用一個工具類，統一管理不容易出錯。

九、單點退出

這個比較簡單，把你的退出鏈接設置為：https://sso.wsria.com/cas/logout 即可。

十、美化CAS服務器界面

CAS服務端(cas-server)的界面只能在測試的時候用一下，真正系統上線肯定需要定制開發自己的頁面，就像網易和CSDN的統一認證平臺一樣，所有子系統的認證都通過此平臺來轉接，大家可以根據他們的頁面自己定制出適合所屬應用或者公司的界面；簡單介紹一下吧，復制cas\WEB-INF\view\jsp\default\ui的一些JSP文件，每一個文件的用途文件名已經區分了，自己修改了替換一下就可以了。例如：

• 登錄界面：casLoginView.jsp
• 登錄成功：casGenericSuccess.jsp
• 登出界面：casLogoutView.jsp

十一、結束語

花了一下午時間終於寫完了，總共十項也算完美了。現在看來起始利用CAS實現單點登錄其實不難，不要畏懼，更不要排斥！本教程後面的代碼部分均來自http://code.google.com/p/wsria的項目分支wsria-demo-sso

和本教程相關資料下載

• 本教程使用的演示程序，點擊這裏
• 使用keytool生成的key和證書，點擊這裏

到此本教程全部結束，希望看完後對你有幫助，如果有幫助還望繼續推薦給其他人，有說明意見或者問題請回復或者IM聯系我。

十二、疑難問題

如果遇到了意料之外的問題請參考文章的評論部分，或許能找到問題的原因以及解決辦法！

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching casserver found

由於創建證書的域名和在應用中配置的cas服務域名不一致導致以下錯誤，詳細請參考：

十三、更新記錄_2011-11-05

整整一年之後因為需要為客戶搭建CAS換季再次更新本文章，不知道碰巧呢碰巧呢還是碰巧呢，反正就是11.5號了……在這裏還要感謝大家對我的支持，要不然這篇教程也不會一直處於本博客的第一位……

不知道從哪個版本開始cas全面使用了maven構建項目，所以需要安裝apache maven工具來構建源碼，下面step by step講解如何構建（面向沒有接觸過maven的童鞋）

• 下載Maven：打開http://maven.apache.org/download.html後下載對應的包，windows用戶請下載Binary zip格式的壓縮包，linux或者unix用戶請下載Binary tar.gz**格式的壓縮包

• 安裝、配置Maven：解壓壓縮包到一個目錄，例如/home/kafeitu/tools/apache/apache-maven-3.0.3，然後設置系統環境變量M3_HOME=/home/kafeitu/tools/apache/apache-maven-3.0.3，在PAT變量中添加路徑

  • windows用戶：;%M3_HOME%/bin
  • Linux用戶：在.bashrc或者/et/profile文件中找到PATH，添加:$M3_HOME/bin

• 驗證安裝：重新打開一個命令窗口，

  • linux用戶可以運行： ?

    1	source .bashrc

    或者 ?

    1	source /etc/profile

  • windows用戶重新打開cmd窗口

在cmd或者shell中進入解壓的cas server目錄後運行:mvn -version後如果看到打印系統信息和maven版本信息後證明配置ok

十四、更新記錄_2011-11-18

你也可以申請免費的StartSSL CA證書:StartSSL(公司名：StartCom)也是一家CA機構，它的根證書很久之前就被一些具有開源背景的瀏覽器支持(Firefox瀏覽器、谷歌Chrome瀏覽器、蘋果Safari瀏覽器等)。申請地址：http://www.startssl.com申請方法參考：http://www.linuxidc.com/Linux/2011-11/47478.htm

cas協議，以及tomcat搭建cas服務器