CAS 單點登入簡介

前一段時間，公司項目因為要與其他項目之間進行內建，弄成一個整體的大項目，因為各個項目都是老項目了，每一個項目都有一個自己的登入過濾機制，這時的需求就變成了隻需一次登入，就可以登入進去其他子項目，不用每次通路其他項目都需要登入一次。

這個任務就交給了我這個剛畢業參加工作沒多久的身上，說實話，對我來說還是挺難的。後來在網上查找各種資料，就標明了用的比較多的成熟架構 CAS 。在實際開發中，也碰到了很多各種各樣的問題，在這裡把自己對 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 使用的總結。