[[408069]]

 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 的整個登錄過程中，有三個重要的概念，這里我先來和大家捋一捋。

• TGT：TGT 全稱叫做 Ticket Granting Ticket，這個相當于我們平時所見到的 HttpSession 的作用，用戶登錄成功后，用戶的基本信息，如用戶名、登錄有效期等信息，都將存儲在此。
• TGC：TGC 全稱叫做 Ticket Granting Cookie，TGC 以 Cookie 的形式保存在瀏覽器中，根據 TGC 可以幫助用戶找到對應的 TGT，所以這個 TGC 有點類似與會話 ID。
• 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 發現用戶沒有登錄，于是返回 302，并且攜帶上一個 service 參數，讓用戶去 CAS Server 上登錄。
• 瀏覽器自動重定向到 CAS Server 上，CAS Server 獲取用戶 Cookie 中攜帶的 TGC，去校驗用戶是否已經登錄，如果已經登錄，則完成身份校驗(此時 CAS Server 可以根據用戶的 TGC 找到 TGT，進而獲取用戶的信息);如果未登錄，則重定向到 CAS Server 的登錄頁面，用戶輸入用戶名/密碼，CAS Server 會生成 TGT，并且根據 TGT 簽發一個 ST，再將 TGC 放在用戶的 Cookie 中，完成身份校驗。
• CAS Server 完成身份校驗之后，會將 ST 拼接在 service 中，返回 302，瀏覽器將首先將 TGC 存在 Cookie 中，然后根據 302 的指示，攜帶上 ST 重定向到應用1。
• 應用1 收到瀏覽器傳來的 ST 之后，拿去 CAS Server 上校驗，去判斷用戶的登錄狀態，如果用戶登錄合法，CAS Server 就會返回用戶信息給 應用1。
• 瀏覽器再去訪問應用2，應用2 發現用戶未登錄，重定向到 CAS Server。
• CAS Server 發現此時用戶實際上已經登錄了，于是又重定向回應用2，同時攜帶上 ST。
• 應用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 客戶端～

本文轉載自微信公眾號「江南一點雨」，可以通過以下二維碼關注。轉載本文請聯系江南一點雨公眾號。