CAS實現單點登陸SSO執行原理及部署

1、不落俗套的開始

一、背景介紹

單點登陸:Single Sign On,簡稱SSO,SSO使得在多個應用系統中,用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。html

CAS框架:CAS(Central Authentication Service)是實現SSO單點登陸的框架。java

二、盜一張學習CAS絕大多都看過的圖以及執行部分分析

注:已分不清原創,此處就不給出地址了。web

這裏寫圖片描述

從結構上看,CAS包含兩個部分:CAS Server 和CAS Client須要獨立部署,主要負責對用戶的認證工做;CAS 
Client負責處理對客戶端受保護資源的訪問請求,須要登陸時,重定向到CAS Server.圖1是CAS最基本的協議過程:apache

CAS Client 與受保護的客戶端應用部署在一塊兒,以Filter方式保護 Web 應用的受保護資源,過濾從客戶端過來的每個 Web 
請求,同時, CAS Client會分析HTTP 請求中是否包請求 Service Ticket( 上圖中的 Ticket) 
,若是沒有,則說明該用戶是沒有通過認證的,因而,CAS Client會重定向用戶請求到CAS Server( Step 2 )。 Step 
3是用戶認證過程,若是用戶提供了正確的Credentials, CAS Server 會產生一個隨機的 Service Ticket 
,而後,緩存該 Ticket ,而且重定向用戶到CAS Client(附帶剛纔產生的Service Ticket), Service 
Ticket 是不能夠僞造的,最後, Step 5 和 Step6是 CAS Client 和 CAS 
Server之間完成了一個對用戶的身份覈實,用Ticket查到 Username ,由於 Ticket是 CAS Server 
產生的,所以,因此 CAS Server 的判斷是毋庸置疑的。windows

該協議完成了一個很簡單的任務,全部與CAS的交互均採用SSL協議,確保ST和TGC的安全性。協議工做過程會有2此重定向過程,可是CAS 
Client與CAS Server之間進行ticket驗證的過程對於用戶是透明的。瀏覽器

總結一下,以下:緩存

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

定向認證: SSO 客戶端會重定向用戶請求到 SSO 服務器。安全

用戶認證:用戶身份認證。服務器

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

驗證票據: SSO 服務器驗證票據 Service Ticket 的合法性,驗證經過後,容許客戶端訪問服務。

傳輸用戶信息: SSO 服務器驗證票據經過後,傳輸用戶認證結果信息給客戶端。

2、在雲裏霧裏進一步搜索、探究

先給出此部份內容出處: 《SSO CAS單點系列》之 實現一個SSO認證服務器是這樣的,如下標紅部分爲本身的疑問。

一、登陸信息傳遞

這裏寫圖片描述 
用戶首次登陸時流程以下:

1)、用戶瀏覽器訪問系統A需登陸受限資源,此時進行登陸檢查,發現未登陸,而後進行獲取票據操做,發現沒有票據。

2)、系統A發現該請求須要登陸,將請求重定向到認證中心,獲取全局票據操做,沒有,進行登陸。

3)、認證中心呈現登陸頁面,用戶登陸,登陸成功後,認證中心重定向請求到系統A,並附上認證經過令牌,此時認證中心同時生成了全局票據。

4)、此時再次進行登陸檢查,發現未登陸,而後再次獲取票據操做,此時能夠得到票據(令牌),系統A與認證中心通訊,驗證令牌有效,證實用戶已登陸。

5)、系統A將受限資源返給用戶。

這裏寫圖片描述 
已登陸用戶首次訪問應用羣中系統B時:

1)、瀏覽器訪問另外一應用B需登陸受限資源,此時進行登陸檢查,發現未登陸,而後進行獲取票據操做,發現沒有票據。

2)、系統B發現該請求須要登陸,將請求重定向到認證中心,獲取全局票據操做,獲取全局票據,能夠得到,認證中心發現已經登陸

3)、認證中心發放臨時票據(令牌),並攜帶該令牌重定向到系統B。

4)、此時再次進行登陸檢查,發現未登陸,而後再次獲取票據操做,此時能夠得到票據(令牌),系統B與認證中心通訊,驗證令牌有效,證實用戶已登陸。

5)、系統B將受限資源返回給客戶端。

二、登陸狀態判斷

用戶到認證中心登陸後,用戶和認證中心之間創建起了會話,咱們把這個會話稱爲全局會話。當用戶後續訪問系統應用時,咱們不可能每次應用請求都到認證中心去斷定是否登陸,這樣效率很是低下,這也是單Web應用不須要考慮的。

咱們能夠在系統應用和用戶瀏覽器之間創建起局部會話,局部會話保持了客戶端與該系統應用的登陸狀態,局部會話依附於全局會話存在,全局會話消失,局部會話必須消失。

用戶訪問應用時,首先判斷局部會話是否存在,如存在,即認爲是登陸狀態,無需再到認證中心去判斷。如不存在,就重定向到認證中心判斷全局會話是否存在,如存在,按1提到的方式通知該應用,該應用與客戶端就創建起它們之間局部會話,下次請求該應用,就不去認證中心驗證了。

三、登出

用戶在一個系統登出了,訪問其它子系統,也應該是登出狀態。要想作到這一點,應用除結束本地局部會話外,還應該通知認證中心該用戶登出。

認證中心接到登出通知,便可結束全局會話,同時須要通知全部已創建局部會話的子系統,將它們的局部會話銷燬。這樣,用戶訪問其它應用時,都顯示已登出狀態。

整個登出流程以下:

1)、客戶端嚮應用A發送登出Logout請求。 
2)、應用A取消本地會話,同時通知認證中心,用戶已登出。 
3)、應用A返回客戶端登出請求。 
4)、認證中心通知全部用戶登陸訪問的應用,用戶已登出。

3、撥開雲霧見青天

一、對上面全部標紅疑問一一解釋

1)、問:系統A是如何發現該請求須要登陸重定向到認證中心的? 
答:用戶經過瀏覽器地址欄訪問系統A,系統A(也能夠稱爲CAS客戶端)去Cookie中拿JSESSION,即在Cookie中維護的當前回話session的id,若是拿到了,說明用戶已經登陸,若是未拿到,說明用戶未登陸。

2)、問:系統A重定向到認證中心,發送了什麼信息或者地址變成了什麼? 
答:假如系統A的地址爲http://a:8080/,CAS認證中心的服務地址爲http://cas.server:8080/,那麼重點向先後地址變化爲:http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/,由此可知,重點向到認證中心,認證中心拿到了當前訪問客戶端的地址。

3)、問:登陸成功後,認證中心重定向請求到系統A,認證經過令牌是如何附加發送給系統A的? 
答:重定向以後的地址欄變成:http://a:8080/?ticket=ST-XXXX-XXX,將票據以ticket爲參數名的方式經過地址欄發送給系統A

4)、問:系統A驗證令牌,怎樣操做證實用戶登陸的? 
答:系統A經過地址欄獲取ticket的參數值ST票據,而後從後臺將ST發送給CAS server認證中心驗證,驗證ST有效後,CAS server返回當前用戶登陸的相關信息,系統A接收到返回的用戶信息,併爲該用戶建立session會話,會話id由cookie維護,來證實其已登陸。

5)、問:登陸B系統,認證中心是如何判斷用戶已經登陸的? 
答:在系統A登陸成功後,用戶和認證中心之間創建起了全局會話,這個全局會話就是TGT(Ticket Granting Ticket),TGT位於CAS服務器端,TGT並無放在Session中,也就是說,CAS全局會話的實現並無直接使用Session機制,而是利用了Cookie本身實現的,這個Cookie叫作TGC(Ticket Granting Cookie),它存放了TGT的id,保存在用戶瀏覽器上。 
相關內容分析能夠查看:《SSO CAS單點系列》之 實操!輕鬆玩轉SSO CAS就這麼簡單(相識篇)

用戶發送登陸系統B的請求,首先會去Cookie中拿JSESSION,由於系統B並未登陸過,session會話還未建立,JSESSION的值是拿不到的,而後將請求重定向到CAS認證中心,CAS認證中心先去用戶瀏覽器中拿TGC的值,也就是全局會話id,若是存在則表明用戶在認證中心已經登陸,附帶上認證令牌重定向到系統B。

上面登陸狀態判斷也是這個邏輯。

6)、問:登出的過程,各個系統對當前用戶都作了什麼? 
答:認證中心清除當前用戶的全局會話TGT,同時清掉cookie中TGT的id:TGC; 
而後是各個客戶端系統,好比系統A、系統B,清除局部會話session,同時清掉cookie中session會話id:jsession

二、對系統A登陸流程圖添加註釋,查看

這裏寫圖片描述

無論了,反正我看懂了。

ps:看到這裏的福利,cas系列介紹文章分享:CAS介紹資源頁面

部署目錄:

  • 1、概述
  • 2、演示環境
  • 3、JDK安裝配置
  • 4、安全證書配置
  • 5、部署CAS-Server相關的Tomcat
  • 6、部署CAS-Client相關的Tomcat
  • 7、 測試驗證SSO

1、概述

此文的目的就是爲了幫助初步接觸SSO和CAS 的人員提供一個入門指南,一步一步演示如何實現基於CAS的單點登陸。

CAS的官網:http://www.jasig.org/cas

2、演示環境

本文演示過程在同一個機器上的(也能夠在三臺實體機器或者三個的虛擬機上),環境以下:

  • windows7 64位,主機名稱:michael-pc
  • JDK 1.6.0_18
  • Tomcat 6.0.29
  • CAS-server-3.4.十一、CAS-client-3.2.1
根據演示需求,用修改hosts 文件的方法添加域名最簡單方便(這個很是重要),在文件 C:\Windows\System32\drivers\etc\hosts 文件中添加三條

 

 

  • demo.micmiu.com  =>> 對應部署cas server的tomcat,這個虛擬域名還用於證書生成
  • app1.micmiu.com  =>>  對應部署app1 的tomcat
  • app2.micmiu.com   =>> 對應部署app2 的tomcat
 

3、JDK安裝配置

這個詳細過程就不在描述,若是是免安裝版的,確保環境變量配置正確。

本機環境變量:JAVA_HOME=D:\jdk,若是看到如下信息則表示安裝成功:

4、安全證書配置

有關keytool工具的詳細運用見:http://www.micmiu.com/lang/java/keytool-start-guide/

4.1. 生成證書:

ps:

  • 截圖中須要輸入的姓名和上面hosts文件中配置的一致;
  • keypass 和 storepass 兩個密碼要一致,不然下面tomcat 配置https 訪問失敗;

4.2.導出證書:

4.3.客戶端導入證書:

ps:該命令中輸入的密碼和上面輸入的不是同一個密碼;若是是多臺機器演示,須要在每一臺客戶端導入該證書。

5、部署CAS-Server相關的Tomcat

5.1. 配置HTTPS

解壓apache-tomcat-6.0.29.tar.gz並重命名後的路徑爲 G:\sso\tomcat-cas,在文件 conf/server.xml文件找到:

修改爲以下:

參數說明:

  • keystoreFile 就是4.1中建立證書的路徑
  • keystorePass 就是4.1中建立證書的密碼

5.2. 驗證HTTPS配置
其餘按照默認配置不做修改,雙擊%TOMCAT_HOME%\bin\startup.bat 啓動tomcat-cas 驗證https訪問配置:


若是看到上述界面表示https 訪問配置成功。

5.3 部署CAS-Server
CAS-Server 下載地址:http://www.jasig.org/cas/download
本文以cas-server-3.4.11-release.zip 爲例,解壓提取cas-server-3.4.11/modules/cas-server-webapp-3.4.11.war文件,把改文件copy到 G:\sso\tomcat-cas\webapps\ 目下,並重命名爲:cas.war.
啓動tomcat-cas,在瀏覽器地址欄輸入:https://demo.micmiu.com:8443/cas/login ,回車

CAS-server的默認驗證規則:只要用戶名和密碼相同就認證經過(僅僅用於測試,生成環境須要根據實際狀況修改),輸入admin/admin 點擊登陸,就能夠看到登陸成功的頁面:

看到上述頁面表示CAS-Server已經部署成功。

6、部署CAS-Client相關的Tomcat

6.1Cas-Client 下載

CAS-Client 下載地址:http://downloads.jasig.org/cas-clients/

以cas-client-3.2.1-release.zip 爲例,解壓提取cas-client-3.2.1/modules/cas-client-core-3.2.1.jar

藉以tomcat默認自帶的 webapps\examples 做爲演示的簡單web項目

6.2 安裝配置 tomcat-app1

解壓apache-tomcat-6.0.29.tar.gz並重命名後的路徑爲 G:\sso\tomcat-app1,修改tomcat的啓動端口,在文件 conf/server.xml文件找到以下內容:

修改爲以下:

啓動tomcat-app1,瀏覽器輸入 http://app1.micmiu.com:18080/examples/servlets/ 回車:

看到上述界面表示tomcat-app1的基本安裝配置已經成功。

接下來複制 client的lib包cas-client-core-3.2.1.jar到 tomcat-app1\webapps\examples\WEB-INF\lib\目錄下, 在tomcat-app1\webapps\examples\WEB-INF\web.xml 文件中增長以下內容:

有關cas-client的web.xml修改的詳細說明見官網介紹:

https://wiki.jasig.org/display/CASC/Configuring+the+Jasig+CAS+Client+for+Java+in+the+web.xml

6.3 安裝配置 tomcat-app2

解壓apache-tomcat-6.0.29.tar.gz並重命名後的路徑爲 G:\sso\tomcat-app2,修改tomcat的啓動端口,在文件 conf/server.xml文件找到以下內容:

修改爲以下:

啓動tomcat-app2,瀏覽器輸入 http://app2.micmiu.com:28080/examples/servlets/ 回車,按照上述6.2中的方法驗證是否成功。

同6.2中的複製 client的lib包cas-client-core-3.2.1.jar到 tomcat-app2\webapps\examples\WEB-INF\lib\目錄下, 在tomcat-app2\webapps\examples\WEB-INF\web.xml 文件中增長以下內容:

7、 測試驗證SSO

啓動以前配置好的三個tomcat分別爲:tomcat-cas、tomcat-app一、tomcat-app2.

7.1  基本的測試

預期流程: 打開app1 url —-> 跳轉cas server 驗證 —-> 顯示app1的應用 —-> 打開app2 url —-> 顯示app2 應用 —-> 註銷cas server —-> 打開app1/app2 url —-> 從新跳轉到cas server 驗證.

打開瀏覽器地址欄中輸入:http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample,回車:

跳轉到驗證頁面:

驗證經過後顯示以下:

此時訪問app2就再也不須要驗證:

地址欄中輸入:https://demo.micmiu.com:8443/cas/logout,回車顯示:

上述表示 認證註銷成功,此時若是再訪問 : http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample 或 http://app2.micmiu.com:28080/examples/servlets/servlet/HelloWorldExample 須要從新進行認證。

7.2  獲取登陸用戶的信息

修改類:webapps\examples\WEB-INF\classes\HelloWorldExample.java 後從新編譯並替換 webapps\examples\WEB-INF\classes\HelloWorldExample.class文件。

 HelloWorldExample.java 修改後的代碼以下:

再進行上述測試顯示結果以下:

http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample :

http://app2.micmiu.com:28080/examples/servlets/servlet/HelloWorldExample

從上述頁面能夠看到經過認證的用戶名。

到此已經所有完成了CAS單點登陸實例演示。

相關文章
相關標籤/搜索