CAS ( Central Authentication Service ) 是 Yale 大學發起的一個企業級的、開源的項目,旨在爲 Web 應用系統提供一種可靠的單點登陸解決方法(屬於 Web SSO )。html
CAS 開始於 2001 年, 並在 2004 年 12 月正式成爲 JA-SIG 的一個項目。前端
一、 開源的、多協議的 SSO 解決方案; Protocols : Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。java
二、 支持多種認證機制: Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates等;mysql
三、 安全策略:使用票據( Ticket )來實現支持的認證協議;linux
四、 支持受權:能夠決定哪些服務能夠請求和驗證服務票據( Service Ticket );程序員
五、 提供高可用性:經過把認證過的狀態數據存儲在 TicketRegistry 組件中,這些組件有不少支持分佈式環境的實現,如: BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等;web
六、 支持多種客戶端: Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。算法
本文內容主要針對 Web SSO 。spring
單點登陸( Single Sign-On , 簡稱 SSO )是目前比較流行的服務於企業業務整合的解決方案之一, SSO 使得在多個應用系統中,用戶只須要 登陸一次 就能夠訪問全部相互信任的應用系統。sql
通常 SSO 體系主要角色有三種:
一、 User (多個)
二、 Web 應用(多個)
三、 SSO 認證中心( 1 個 )
SSO 實現模式通常包括如下三個原則:
一、 全部的認證登陸都在 SSO 認證中心進行;
二、 SSO 認證中心經過一些方法來告訴 Web 應用當前訪問用戶到底是不是已經過認證的用戶;
三、 SSO 認證中心和全部的 Web 應用創建一種信任關係,也就是說 web 應用必須信任認證中心。(單點信任)
SSO 的主要實現方式有:
一、 共享 cookies
基於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式,它利用瀏覽同域名之間自動傳遞 cookies 機制,實現兩個域名之間系統令牌傳遞問題;另外,關於跨域問題,雖然 cookies 自己不跨域,但能夠利用它實現跨域的 SSO 。如:代理、暴露 SSO 令牌值等。
缺點:不靈活並且有很多安全隱患,已經被拋棄。
二、 Broker-based( 基於經紀人 )
這種技術的特色就是,有一個集中的認證和用戶賬號管理的服務器。經紀人給被用於進一步請求的電子身份存取。中央數據庫的使用減小了管理的代價,併爲認證提供一個公共和獨立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight (憑證庫思想 ) 等。 Kerberos是由麻省理工大學發明的安全認證服務,已經被 UNIX 和 Windows 做爲默認的安全認證服務集成進操做系統。
三、 Agent-based (基於代理人)
在這種解決方案中,有一個自動地爲不一樣的應用程序認證用戶身份的代理程序。這個代理程序須要設計有不一樣的功能。好比,它可使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在服務器上面,在服務器的認證系統和客戶端認證方法之間充當一個 " 翻譯 " 。例如 SSH 等。
四、 Token-based
例如 SecureID,WebID ,如今被普遍使用的口令認證,好比 FTP 、郵件服務器的登陸認證,這是一種簡單易用的方式,實現一個口令在多種應用當中使用。
五、 基於網關
六、 基於 SAML
SAML(Security Assertion Markup Language ,安全斷言標記語言)的出現大大簡化了 SSO ,並被 OASIS 批准爲 SSO 的執行標準 。開源組織 OpenSAML 實現了 SAML 規範。
從結構體系看, CAS 包括兩部分: CAS Server 和 CAS Client 。
CAS Server 負責完成對用戶的認證工做 , 須要獨立部署 , CAS Server 會處理用戶名 / 密碼等憑證(Credentials) 。
負責處理對客戶端受保護資源的訪問請求,須要對請求方進行身份認證時,重定向到 CAS Server 進行認證。(原則上,客戶端應用再也不接受任何的用戶名密碼等 Credentials )。
CAS Client 與受保護的客戶端應用部署在一塊兒,以 Filter 方式保護受保護的資源。
基礎模式 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 隨機產生一個至關長度、惟1、不可僞造的 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 請求認證時序圖以下:
當用戶訪問另外一個應用的服務再次被重定向到 CAS Server 的時候, CAS Server 會主動獲到這個 TGC cookie ,而後作下面的事情:
1) 若是 User 持有 TGC 且其還沒失效,那麼就走基礎協議圖的 Step4 ,達到了 SSO 的效果;
2) 若是 TGC 失效,那麼用戶仍是要從新認證 ( 走基礎協議圖的 Step3) 。
該模式形式爲用戶訪問 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 。
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 的交互而已。
CAS 系統中設計了 5 中票據: TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
其它說明以下:
CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。
對於一個 CAS 用戶來講,最重要是要保護它的 TGC ,若是 TGC 不慎被 CAS Server 之外的實體得到, Hacker 可以找到該 TGC ,而後冒充 CAS 用戶訪問 全部 受權資源。 PGT 的角色跟 TGC 是同樣的。
從基礎模式能夠看出, TGC 是 CAS Server 經過 SSL 方式發送給終端用戶,所以,要截取 TGC 難度很是大,從而確保 CAS 的安全性。
TGT 的存活週期默認爲 120 分鐘。
ST ( Service Ticket )是經過 Http 傳送的,所以網絡中的其餘人能夠 Sniffer 到其餘人的 Ticket。 CAS 經過如下幾方面來使 ST 變得更加安全(事實上都是能夠配置的):
一、 ST 只能使用一次
CAS 協議規定,不管 Service Ticket 驗證是否成功, CAS Server 都會清除服務端緩存中的該 Ticket ,從而能夠確保一個 Service Ticket 不被使用兩次。
二、 ST 在一段時間內失效
CAS 規定 ST 只能存活必定的時間,而後 CAS Server 會讓它失效。默認有效時間爲 5 分鐘。
三、 ST 是基於隨機數生成的
ST 必須足夠隨機,若是 ST 生成規則被猜出, Hacker 就等於繞過 CAS 認證,直接訪問 對應的服務。
一、 https://wiki.jasig.org/display/CASUM/Introduction
二、 http://www.jasig.org/cas/protocol/
三、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html
四、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html
五、 http://baike.baidu.com/view/190743.htm
CAS單點登陸(SSO)完整教程(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怎麼導入證書。
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)的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
>
|
好了,到此Tomcat的SSL啓用完成,如今你能夠啓動tomcat試一下了,例如本教程輸入地址:https://sso.wsria.com:8443/打開的是:
好的,那麼咱們點擊「繼續瀏覽此網站(不推薦)。如今進入Tomcat目錄了吧,若是是那麼你又向成功邁進了一步。
OK,接下來要配置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默認的驗證規則只要用戶名和密碼相同就經過)因此若是你看到下面的這張圖片你就成功了
你成功了嗎?若是沒有成功請再檢查以上步驟!
使用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服務器怎麼讀取數據庫的信息進行身份驗證。首先打開
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
=
"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;
|
添加cas-client的jar包,有兩種方式:
下載cas-client,地址:http://www.ja-sig.org/downloads/cas-clients/,而後解壓cas-client-3.1.12.zip,在modules文件夾中有須要的jar包,請根據本身的項目狀況選擇使用
用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目錄中
1
2
3
4
5
|
<
dependency
>
<
groupid
>org.jasig.cas.client
groupid
>
<
artifactid
>cas-client-core
artifactid
>
<
version
>3.1.12
version
>
dependency
>
|
編輯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
>
init-param
>
<
init-param
>
<
param-name
>serverName
param-name
>
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
>
init-param
>
<
init-param
>
<
param-name
>serverName
param-name
>
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.java的源碼
好的,若是你是老程序員應該很快就清楚Filter的目的,若是不太懂我再講解一下;主要是經過CAS的const_cas_assertion獲取從CAS服務器登錄的用戶名,而後再根據系統內部的用戶工具(UserUtil.java)來判斷是否已經登陸過,若是沒有登陸根據登陸名從數據庫查詢用戶信息,最後使用設置把用戶信息設置到當前session中。這樣就把用戶信息保存到了Sessino中,咱們就能夠經過UserUtil工具來獲取當前登陸的用戶了,我在實例項目中也加入了此功能演示,請看代碼:main.jsp的第44行處
若是是爲一個老項目添加單點登陸功能,那麼基本不須要其餘的修改,設置好上面的filter便可;固然最好獲取用戶信息的地方都調用一個工具類,統一管理不容易出錯。
這個比較簡單,把你的退出連接設置爲:https://sso.wsria.com/cas/logout 便可。
CAS服務端(cas-server)的界面只能在測試的時候用一下,真正系統上線確定須要定製開發本身的頁面,就像網易和CSDN的統一認證平臺同樣,全部子系統的認證都經過此平臺來轉接,你們能夠根據他們的頁面本身定製出適合所屬應用或者公司的界面;簡單介紹一下吧,複製cas\WEB-INF\view\jsp\default\ui的一些JSP文件,每個文件的用途文件名已經區分了,本身修改了替換一下就能夠了。例如:
花了一下午時間終於寫完了,總共十項也算完美了。如今看來起始利用CAS實現單點登陸其實不難,不要畏懼,更不要排斥!本教程後面的代碼部分均來自http://code.google.com/p/wsria的項目分支wsria-demo-sso
到此本教程所有結束,但願看完後對你有幫助,若是有幫助還望繼續推薦給其餘人,有說明意見或者問題請回復或者IM聯繫我。
若是遇到了意料以外的問題請參考文章的評論部分,或許能找到問題的緣由以及解決辦法!
因爲建立證書的域名和在應用中配置的cas服務域名不一致致使如下錯誤,詳細請參考:
整整一年以後由於須要爲客戶搭建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變量中添加路徑
驗證安裝:從新打開一個命令窗口,
1
|
source
.bashrc
|
1
|
source
/etc/profile
|
在cmd或者shell中進入解壓的cas server目錄後運行:mvn -version後若是看到打印系統信息和maven版本信息後證實配置ok
你也能夠申請免費的StartSSL CA證書:StartSSL(公司名:StartCom)也是一家CA機構,它的根證書好久以前就被一些具備開源背景的瀏覽器支持(Firefox瀏覽器、谷歌Chrome瀏覽器、蘋果Safari瀏覽器等)。申請地址:http://www.startssl.com申請方法參考:http://www.linuxidc.com/Linux/2011-11/47478.htm