1、基於cookie的單點登入的回顧
基於cookie的單點登入核心原理：
2、統一認證中心方案原理
在生活中我們也有類似的相關生活經驗，例如你去食堂吃飯，食堂打飯的阿姨（www.qiandu.com）告訴你，不收現金。並且告訴你，你去門口找換票的（passport.com）換小票。於是你換完票之後，再去找食堂阿姨，食堂阿姨拿著你的票，問門口換票的，這個票是真的嗎？換票的說，是真的，於是給你打飯了。
基於上述生活中的場景，我們將基於cookie的單點登入改良以後的方案如下：
3、yelu大學研發的cas(central authentication server)
下面就以耶魯大學研發的cas為分析依據，分析其工作原理。首先看一下最上層的專案部署圖：
4、cas的詳細登入流程
上圖是3個登入場景，分別為：第一次訪問www.qiandu.com、第二次訪問、以及登入狀態下第一次訪問mail.qiandu.com。
下面就詳細說明上圖中每個數字標號做了什麼，以及相關的請求內容，響應內容。
標號3：瀏覽器接收到重定向之後發起重定向，請求cas.qiandu.com。
標號4：認證中心cas.qiandu.com接收到登入請求，返回登陸頁面。
標號5：使用者在cas.qiandu.com的login頁面輸入使用者名稱密碼，提交。
標號6：伺服器接收到使用者名稱密碼，則驗證是否有效，驗證邏輯可以使用cas-server提供現成的，也可以自己實現。
標號7：瀏覽器從cas.qiandu.com**拿到ticket之後，就根據指示重定向到www.qiandu.com，請求的url就是上面返回的url。
標號8：www.qiandu.com在過濾器中會取到ticket的值，然後通過http方式呼叫cas.qiandu.com驗證該ticket是否是有效的。
標號9：cas.qiandu.com接收到ticket之後，驗證，驗證通過返回結果告訴www.qiandu.com該ticket有效。
4.2、第二次訪問www.qiandu.com
上面以及訪問過一次了，當第二次訪問的時候發生了什麼呢？
標號11：使用者發起請求，訪問www.qiandu.com。會經過cas-client，也就是過濾器，因為第一次訪問成功之後www.qiandu.com中會在session中記錄使用者資訊，因此這裡直接就通過了，不用驗證了。
標號12：使用者通過許可權驗證，瀏覽器返回正常資源。
4.3、訪問mail.qiandu.com
標號13：使用者在www.qiandu.com正常上網，突然想訪問mail.qiandu.com，於是發起訪問mail.qiandu.com的請求。
標號16：認證中心收到請求，發現tgc對應了乙個tgt，於是用tgt簽發乙個st，並且返回給瀏覽器，讓他重定向到mail.qiandu.com
標號18：mail.qiandu.com獲取ticket去認證中心驗證是否有效。
標號19：認證成功，返回在mail.qiandu.com的session中設定登入狀態，下次就直接登入。
標號20：認證成功之後就反正用想要訪問的資源了。
5、總結
至此，cas登入的整個過程就完畢了，以後有時間總結下如何使用cas，並運用到專案中。
cas原理介紹
cas用來標誌使用者的token是存在它自己的網域名稱下的,不是存在web應用的網域名稱下的.cas判斷使用者登入由agent決定,agent驗證使用者資訊有兩種處理.1.如果這個使用者是以前沒登入過的,也就是說這個web應用的網域名稱下沒有乙個agent頒發的sessionid 在cookie裡 ...
cas原理介紹
cas用來標誌使用者的token是存在它自己的網域名稱下的,不是存在web應用的網域名稱下的.cas判斷使用者登入由agent決定,agent驗證使用者資訊有兩種處理.1.如果這個使用者是以前沒登入過的,也就是說這個web應用的網域名稱下沒有乙個agent頒發的sessionid 在cookie裡 ...
cas原理介紹
cas用來標誌使用者的token是存在它自己的網域名稱下的,不是存在web應用的網域名稱下的.cas判斷使用者登入由agent決定,agent驗證使用者資訊有兩種處理.1.如果這個使用者是以前沒登入過的,也就是說這個web應用的網域名稱下沒有乙個agent頒發的sessionid 在cookie裡 ...