阿里P8Java架構師手把手教你入門 Spring Boot + CAS 單點登錄

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 登錄過程是什麼樣子的！

 

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

術語：應用1、應用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、應用1、應用2 建立了會話，其中，和 CAS Server 建立的會話稱之爲全局會話，和應用1、應用2 建立的會話稱之爲局部會話；一旦局部會話成功建立，以後用戶再去訪問應用1、應用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-overlay-template。

我們在分支中選擇 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 客戶端～