CAS 單點登錄簡介

單點登錄

單點登錄就是一次登錄過後，再沒有退出或者清緩存的情況下，用戶再訪問其他集成了這個功能的項目時，就不需要進行重複的登錄操作，這樣會大大的方便用戶的使用。如果每次都需要用戶登錄一遍，估計這個項目也就沒多少人用了，所以單點登錄這個功能是非常必要的。

CAS

CAS 是耶魯大學開源的一個單點登錄框架，旨在為 web 應用系統提供一個安全可靠的單點登錄框架，最終，在我們公司的項目中選擇了使用 CAS 框架。

名詞解釋

在我們瞭解 CAS 的工作原理之前，我們應該首先了解下在 CAS 裡面的一些概念，這樣對我們理解 CAS 有一個更好的幫助。

ST：Service Ticket，服務票據，服務的唯一標識碼，由 CAS 認證中心生成，返回給用戶，這時 service 拿到 ST 後，又會去到 CAS 驗證中心去驗證，如果驗證成功，則允許用戶訪問資源。

TGC：Ticket Granting Cookie，CAS 系統用來識別用戶身份的憑證。

TGT：Ticket Grangting Ticket，票據授權票據，獲取這個 TGT 後才能申請服務票據（ST），用戶如果在 CA S系統認證成功之後，就會生成 TGC 寫入瀏覽器，同時也生成一個 TGT，TGT 對象的id就是 cookie 值。之後每次請求過來通過此 cookie 來從緩存獲取 TGT，就不用提交身份認證信息（Credentials）。

工作過程

瞭解到上面這些名詞的概念之後，我們來看看下面這一張圖，能更形象的解釋 CAS 的工作流程。

工作原理圖

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

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

用戶認證：用戶身份認證。

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

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

傳輸用戶信息： SSO 服務器驗證票據通過後，傳輸用戶認證結果信息給客戶端。

CAS 分為服務端和客戶端，每一個服務就相當於是一個客戶端，當用戶去訪問一個沒有經過登錄的服務時，會重定向到 CAS Server 提供的登錄界面，不過這個界面我們也可以自定義，也可以使用原客戶端的登錄界面，需要我們自己去做一些修改。輸入完用戶名和密碼後，CAS Server 驗證成功後，會向瀏覽器增加一個加密過的 cookie，也就是 TGC ，用來表明用戶已經成功登錄，這裡保存了用戶的信息，以供其他客戶端使用。同時會重定向到客戶端並且創建一個隨機的，具有唯一標識的 Ticket，也就是 ST，CAS 將 ST 與登錄成功的用戶和服務聯繫在一起，只使用一次，使用過後立刻失效。客戶端接收到 ST 後，會進行校驗，校驗成功後，創建 Session，放開相關資源供用戶使用。當用戶去訪問其他服務時，這時用戶已經成功登錄過了，這時任然會重定向到 CAS Server 端，但是不需要用戶再輸入用戶名和密碼了，而是首先尋找 Cookie，根據其中的信息，進行登錄，CAS 同樣給出新的 ST 重定向到 Server 端校驗，校驗成功則創建 Session，允許訪問。

看到這裡，我們大致能夠明白 CAS 的工作過程，第一步用戶訪問應用服務器重定向到認證服務器（CAS Server），輸入用戶名和密碼，驗證成功後，建立瀏覽器與認證服務器（CAS Server）之間的信任，但是瀏覽器與應用服務器之間並沒有建立信任，所以 ST 是認證服務器返回的，應用服務器拿到這個 ST 後，再去認證服務器驗證是否合法，如果合法，則建立應用服務器與認證服務器之間的信任。TGC 主要的作用是用於單點登錄，當瀏覽器訪問應用服務器2的時候，也會重定向到認證服務器，這時 TGC 存在，不需要輸入用戶名和密碼，直接返回 ST，繼續驗證是否合法，成功則允許訪問。

CAS 的工作過程我們都瞭解了，接下來就是在自己項目的實際配置了，接下來我會繼續分享我在項目中實際應用的情況，希望能夠幫助到大家，同時對我自己也是一次關於 CAS 使用的總結。