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


一、不落俗套的開始

1、背景介紹

單點登錄:Single Sign On,簡稱SSO,SSO使得在多個應用系統中,用戶只需要登錄一次就可以訪問所有相互信任的應用系統。

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

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

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

這里寫圖片描述

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

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 的判斷是毋庸置疑的。

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

總結一下,如下:

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

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

用戶認證:用戶身份認證。

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

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

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

二、在雲里霧里進一步搜索、探究

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

1、登錄信息傳遞

這里寫圖片描述 
用戶首次登錄時流程如下:

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

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

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

4)、此時再次進行登錄檢查,發現未登錄,然后再次獲取票據操作,此時可以獲得票據(令牌),系統A與認證中心通信,驗證令牌有效,證明用戶已登錄。

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

這里寫圖片描述 
已登錄用戶首次訪問應用群中系統B時:

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

2)、系統B發現該請求需要登錄,將請求重定向到認證中心,獲取全局票據操作,獲取全局票據,可以獲得,認證中心發現已經登錄

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

4)、此時再次進行登錄檢查,發現未登錄,然后再次獲取票據操作,此時可以獲得票據(令牌),系統B與認證中心通信,驗證令牌有效,證明用戶已登錄。

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

2、登錄狀態判斷

用戶到認證中心登錄后,用戶和認證中心之間建立起了會話,我們把這個會話稱為全局會話。當用戶后續訪問系統應用時,我們不可能每次應用請求都到認證中心去判定是否登錄,這樣效率非常低下,這也是單Web應用不需要考慮的。

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

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

3、登出

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

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

整個登出流程如下:

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

三、撥開雲霧見青天

1、對上面所有標紅疑問一一解釋

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

2、對系統A登錄流程圖添加注釋,查看

這里寫圖片描述

不管了,反正我看懂了。

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

部署目錄:

  • 一、概述
  • 二、演示環境
  • 三、JDK安裝配置
  • 四、安全證書配置
  • 五、部署CAS-Server相關的Tomcat
  • 六、部署CAS-Client相關的Tomcat
  • 七、 測試驗證SSO

一、概述

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

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

二、演示環境

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

  • windows7 64位,主機名稱:michael-pc
  • JDK 1.6.0_18
  • Tomcat 6.0.29
  • CAS-server-3.4.11、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
 

三、JDK安裝配置

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

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

四、安全證書配置

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

4.1. 生成證書:

ps:

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

4.2.導出證書:

4.3.客戶端導入證書:

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

五、部署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已經部署成功。

六、部署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 文件中增加如下內容:

七、 測試驗證SSO

啟動之前配置好的三個tomcat分別為:tomcat-cas、tomcat-app1、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單點登錄實例演示。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM