鬆哥手把手教你入門 Spring Boot + CAS 單點登陸

在微服務以及分佈式系統中，單點登陸變得愈來愈廣泛，鬆哥以前也有兩篇文章和你們介紹過單點登陸的方案：

• OAuth2+JWT 方案
• @EnableOAuth2Sso 註解方案

這兩種方案中，JWT 存在一個註銷登陸的問題，要費點功夫解決。@EnableOAuth2Sso 註解這種方案不存在註銷登陸的問題，可是又不像 JWT 那麼靈活。

沒有銀彈！

在實際項目中，咱們只能根據本身的實際需求，看一看哪種方案更適合本身，而後在此基礎上進行改造！

如今咱們在 Spring Cloud Security 中使用 OAuth2+JWT 或者使用 @EnableOAuth2Sso 註解比之前要方便不少了，鬆哥也是最近才把項目切換到 Spring Cloud Security 技術棧上面來，在這以前，單點登陸用的更多的是 CAS 單點登陸。相信有很多小夥伴在公司裏可能也仍是使用了 CAS 單點登陸這種方案，今天鬆哥就來花點時間，和你們聊聊 CAS+Spring Security 實現單點登陸，這種方案到底該怎麼玩。

可能會連續幾篇文章來介紹 CAS 單點登陸，本文先來講說理論和登陸流程。另外，因爲 CAS 和 Spring Cloud OAuth2 在某些方面具備必定的類似性，因此強烈建議你們先看一看鬆哥的 OAuth2 系列教程，再來閱讀本文就會輕鬆不少（公衆號後臺回覆 OAuth2 有相關教程）。

本文是 Spring Security 系列第 23 篇，閱讀本系列前面的文章有助於更好的理解本文：

1. 挖一個大坑，Spring Security 開搞！
2. 鬆哥手把手帶你入門 Spring Security，別再問密碼怎麼解密了
3. 手把手教你定製 Spring Security 中的表單登陸
4. Spring Security 作先後端分離，咱就別作頁面跳轉了！通通 JSON 交互
5. Spring Security 中的受權操做原來這麼簡單
6. Spring Security 如何將用戶數據存入數據庫？
7. Spring Security+Spring Data Jpa 強強聯手，安全管理只有更簡單！
8. Spring Boot + Spring Security 實現自動登陸功能
9. Spring Boot 自動登陸，安全風險要怎麼控制？
10. 在微服務項目中，Spring Security 比 Shiro 強在哪？
11. SpringSecurity 自定義認證邏輯的兩種方式(高級玩法)
12. Spring Security 中如何快速查看登陸用戶 IP 地址等信息？
13. Spring Security 自動踢掉前一個登陸用戶，一個配置搞定！
14. Spring Boot + Vue 先後端分離項目，如何踢掉已登陸用戶？
15. Spring Security 自帶防火牆！你都不知道本身的系統有多安全！
16. 什麼是會話固定攻擊？Spring Boot 中要如何防護會話固定攻擊？
17. 集羣化部署，Spring Security 要如何處理 session 共享？
18. 鬆哥手把手教你在 SpringBoot 中防護 CSRF 攻擊！so easy！
19. 要學就學透徹！Spring Security 中 CSRF 防護源碼解析
20. Spring Boot 中密碼加密的兩種姿式！
21. Spring Security 要怎麼學？爲何必定要成體系的學習？
22. Spring Security 兩種資源放行策略，千萬別用錯了！

1.什麼是 CAS

CAS 全稱叫作中央認證服務，英文是 Central Authentication Service。

這是由耶魯大學發起的一個開源項目，目的是幫助 Web 應用系統構建一種可靠的單點登陸解決方案，從目前企業實際項目來看，CAS 仍是很是受歡迎的一種單點登陸解決方案。

1.1 CAS 架構

CAS 分爲兩部分：

• 一個是 CAS Server，這是單點驗證服務，做用相似於咱們OAuth2+JWT 方案中的受權服務器，用來校驗用戶名/密碼等，通常來講都是獨立部署。
• 另外一個則是 CAS Client，至關於就是一個一個的（微）服務。

咱們來看 CAS 的官方給出的一個架構圖：

能夠看到，用戶訪問的是 CAS Clients，CAS Clients 和 CAS Server 之間的通訊支持多種協議，CAS Server 處理具體的認證事宜，CAS Server 對數據源的支持也很是多樣化。

CAS Client 支持的平臺有：

• Apache httpd Server (mod_auth_cas module)
• Java (Java CAS Client)
• .NET (.NET CAS Client)
• PHP (phpCAS)
• Perl (PerlCAS)
• Python (pycas)
• Ruby (rubycas-client)

CAS 支持的通訊協議有：

• CAS (versions 1, 2, and 3)
• SAML 1.1 and 2
• OpenID Connect
• OpenID
• OAuth 2.0
• WS Federation

從圖中也能夠看出 CAS 支持多種不一樣的認證機制，具體有：

• JAAS
• LDAP
• RDBMS
• SPNEGO
• ...

1.2 三個概念

在 CAS 的整個登陸過程當中，有三個重要的概念，這裏我先來和你們捋一捋。

1. TGT：TGT 全稱叫作 Ticket Granting Ticket，這個至關於咱們平時所見到的 HttpSession 的做用，用戶登陸成功後，用戶的基本信息，如用戶名、登陸有效期等信息，都將存儲在此。
2. TGC：TGC 全稱叫作 Ticket Granting Cookie，TGC 以 Cookie 的形式保存在瀏覽器中，根據 TGC 能夠幫助用戶找到對應的 TGT，因此這個 TGC 有點相似與會話 ID。
3. ST：ST 全稱是 Service Ticket，這是 CAS Sever 經過 TGT 給用戶發放的一張票據，用戶在訪問其餘服務時，發現沒有 Cookie 或者 ST ，那麼就會 302 到 CAS Server 獲取 ST，而後會攜帶着 ST 302 回來，CAS Client 則經過 ST 去 CAS Server 上獲取用戶的登陸狀態。

2.CAS 登陸流程

接下來咱們經過一張官方給出的流程圖來看下 CAS 登陸過程是什麼樣子的！

這張圖其實畫的比較清楚了，我再用文字和你們解釋下：

術語：應用一、應用2 分別表示被保護的應用。

1. 用戶經過瀏覽器訪問應用1，應用1 發現用戶沒有登陸，因而返回 302，而且攜帶上一個 service 參數，讓用戶去 CAS Server 上登陸。
2. 瀏覽器自動重定向到 CAS Server 上，CAS Server 獲取用戶 Cookie 中攜帶的 TGC，去校驗用戶是否已經登陸，若是已經登陸，則完成身份校驗（此時 CAS Server 能夠根據用戶的 TGC 找到 TGT，進而獲取用戶的信息）；若是未登陸，則重定向到 CAS Server 的登陸頁面，用戶輸入用戶名/密碼，CAS Server 會生成 TGT，而且根據 TGT 簽發一個 ST，再將 TGC 放在用戶的 Cookie 中，完成身份校驗。
3. CAS Server 完成身份校驗以後，會將 ST 拼接在 service 中，返回 302，瀏覽器將首先將 TGC 存在 Cookie 中，而後根據 302 的指示，攜帶上 ST 重定向到應用1。
4. 應用1 收到瀏覽器傳來的 ST 以後，拿去 CAS Server 上校驗，去判斷用戶的登陸狀態，若是用戶登陸合法，CAS Server 就會返回用戶信息給 應用1。
5. 瀏覽器再去訪問應用2，應用2 發現用戶未登陸，重定向到 CAS Server。
6. CAS Server 發現此時用戶實際上已經登陸了，因而又重定向迴應用2，同時攜帶上 ST。
7. 應用2 拿着 ST 去 CAS Server 上校驗，獲取用戶的登陸信息。

在整個登陸過程當中，瀏覽器分別和 CAS Server、應用一、應用2 創建了會話，其中，和 CAS Server 創建的會話稱之爲全局會話，和應用一、應用2 創建的會話稱之爲局部會話；一旦局部會話成功創建，之後用戶再去訪問應用一、應用2 就不會通過 CAS Server 了。

3.CAS Server 搭建

說了這麼多，來點實際的。

因爲整個 CAS 單點登陸作起來還比較麻煩，咱們一步一步來，今天我先來教你們把 CAS Server 搭建起來。

3.1 版本選擇

目前最新的 CAS Server 是 6.x，這個是基於 gradle 來構建的，考慮到不少小夥伴可能不熟悉 gradle 操做，所以這裏我選擇 5.3 的版本，該版本基於你們熟悉的 maven 來構建。

官方爲咱們提供了構建 CAS Server 的模版，地址是：https://github.com/apereo/cas...。

咱們在分支中選擇 5.3 版本下載：

或者直接 clone 下來，而後切換到 5.3 這個分支也能夠。這個應該就不用我教你們了吧，相信小夥伴們都能本身搞定。

3.2 HTTPS 證書

CAS Server 從版本 4 開始，要使用 HTTPS 通訊，因此咱們得提早準備 HTTPS 證書。公司裏的項目的話，須要購買 HTTPS 證書，本身玩的話也能夠從雲服務廠商那裏申請到免費的 HTTPS 證書。

如今咱們在本地測試，直接利用 JDK 自帶的 keytool 工具，本身生成一個 HTTPS 證書便可。

生成命令以下：

keytool -genkey -alias casserver -keyalg RSA -keystore ./keystore

• -alias 表示生成的證書別名
• -keyalg 表示生成證書使用的算法
• -keystore 表示生成證書的存放位置

證書在執行的時候，須要給一個密鑰庫口令，這個你們隨意給出便可，可是給出了多少要本身記着。另外，在 What is your first and last name? 選項中，須要填入 CAS Server 的域名，這點切記：

如此以後，咱們的 HTTPS 證書就有了，雖然這個證書不被各大廠商承認，可是本身作練習夠用了。

3.3 配置並啓動

接下來進行配置。

咱們在下載的 cas-overlay-template 項目中，新建 src/main/resources 目錄，並將 overlays/org.apereo.cas.cas-server-webapp-tomcat-5.3.14/WEB-INF/classes/application.properties 文件和剛剛生成的 keystore 文件拷貝進來：

而後修改 application.properties ，主要配置一下 keystore 的位置和密鑰，以下:

server.ssl.key-store=classpath:keystore
server.ssl.key-store-password=111111
server.ssl.key-password=111111

配置完成後，在項目根目錄下執行以下命令啓動項目：

./build.sh bootrun

根據我的網速，第一次啓動可能會很是漫長，耐心等待便可。

啓動過程當中，也可能會報錯，可是不用管，若是看到 ready 圖標，就表示啓動成功了：

3.4 測試

啓動成功後，瀏覽器輸入 https://cas.javaboy.org:8443/cas/login 就能夠進入登陸頁面了（注意是 https 哦）：

默認的用戶名是 casuser，密碼是 Mellon，輸入用戶名密碼就能夠登陸了。

默認的用戶名/密碼也能夠在 application.properties 文件中修改，該文件的最後一行：

cas.authn.accept.users=casuser::Mellon

修改完後，重啓項目便可生效。

4.小結

今天主要和小夥伴聊一下 CAS 的基本概念，而後咱們順手搭建一個 CAS Server 出來，感興趣的小夥伴能夠動手試一試哦～，下篇文章咱們來看如何用 Spring Boot 開發 CAS 客戶端～

好啦，若是小夥伴們以爲有收穫，記得點個在看鼓勵下鬆哥哦～