CAS單點登入原理

之前我們談了如何關於單點登入的一些概述，講到了當跨網域名稱單點登入時，cas的設計具有參考價值，那麼這篇就該談談cas的具體原理了。

cas指的是apereo的cas開源專案，三個字母分別是是central authentication service的首字母縮寫。

**：git：

官方文件：

截止目前版本已經更新到了5.3.x

前面我們說到不同網域名稱下如何實現單點登入的問題，現在就可以看看cas如何解決這個問題

cas分為server端和client端兩種

client端：client端是廣義上泛指所有使用cas單點登入的系統，比如a,b兩個系統要設定單點登入，那a,b就都是client，狹義上cas框架提供了client jar包用於其他專案快速接入cas單點登入，

server端：server是用作身份認證用的，通俗的講就是用來校驗使用者名稱密碼的，當然既然要實現多系統單點登入，那肯定不止是校驗使用者名稱密碼，實質是單點登入的核心，統一認證中心。

假設原來有a,b,c三個系統，三個系統各自有各自的登入模組，那麼使用cas單點登入系統進行單點登入後，a,b,c三個系統分別去除掉原有登入模組，同時分別加入cas-client模組作為cas服務的client端，同時會加入乙個新系統，cas-server作為cas的server端。

在說到cas的認證原理時，避免不了st，tgt，tgc的概念，但這些概念相對抽象，這裡我們通過乙個具體的認證過程來進行講解：

先上一張官方時序圖（圖較大）（可先看下方講解）

這張圖基本比較清晰地說明了cas的整個認證實現。

乙個**認證系統cas server

2.重新向至cas server端後，cas server端會進行身份驗證流程，也就是彈出登入頁面，輸入使用者名稱密碼，需要的話還可以自行改造新增驗證碼，簡訊驗證碼等，總的來說cas server端驗證身份成功後會做幾件事

(3)重定向過程中生成乙個名為ticket的引數，格式為st-***x（也就是st）

通過對cas登入流程的粗略分析，我們可以大致了解到cas認證的核心是server端網域名稱下的cookie校驗，通過service引數進行重定向返回接入單點登入系統的專案，通過st做服務驗證，假設不用cas框架，我們現在也可以模仿cas的這一流程做出乙個大致的跨域單點登入系統了。

為了講解連貫，我在上面的步驟描述中忽略了許多細節，比如st實際上只能使用一次，驗證完後就會銷毀，同時其本身有效時間也很短，登入系統，其實涉及很多安全問題，cas框架本身是考慮了安全因素在其中的，我們常見的的安全因素有哪些呢，我將在後續文章中繼續分享。

在登入過程描述中，我提到tgc，tgt與session有關，了解session，cookie的朋友也一定一看到圖就對jsessionid這樣的變數名有所察覺，而談到session就有另乙個避不開的問題，集群。我相信大部分開發人員並不喜歡使用傳統的伺服器session共享，使用redis作為儲存資訊顯然是大部分情況下的更優解，那麼如果使用cas框架能否集群部署，如果不能要如何解決呢，我也將會在後續文章中繼續分析。

CAS單點登入原理

CAS單點登入原理

cas實現單點登入原理

CAS單點登入

相關推薦