基於cookie的單點登入核心原理：
將使用者名稱密碼加密之後存於cookie中，之後訪問**時在過濾器（filter）中校驗使用者許可權，如果沒有許可權則從cookie中取出使用者名稱密碼進行登入，讓使用者從某種意義上覺得只登入了一次。
該方式缺點就是多次傳送使用者名稱密碼，增加被盜風險，以及不能跨域。同時www.qiandu.com與mail.qiandu.com同時擁有登入邏輯的**，如果涉及到修改操作，則需要修改兩處。
在生活中我們也有類似的相關生活經驗，例如你去食堂吃飯，食堂打飯的阿姨（www.qiandu.com）告訴你，不收現金。並且告訴你，你去門口找換票的（passport.com）換小票。於是你換完票之後，再去找食堂阿姨，食堂阿姨拿著你的票，問門口換票的，這個票是真的嗎？換票的說，是真的，於是給你打飯了。
基於上述生活中的場景，我們將基於cookie的單點登入改良以後的方案如下：
經過分析，cookie單點登入認證太過於分散，每個**都持有乙份登陸認證**。於是我們將認證統一化，形成乙個獨立的服務。當我們需要登入操作時，則重定向到統一認證中心於是乎整個流程就如上圖所示：
第一步：使用者訪問www.qiandu.com。過濾器判斷使用者是否登入，沒有登入，則重定向（302）到**
第二步：重定向到passport.com，輸入使用者名稱密碼。passport.com將使用者登入的資訊記錄到伺服器的session中。
第三步：passport.com給瀏覽器傳送乙個特殊的憑證，瀏覽器將憑證交給www.qiandu.com，www.qiandu.com則拿著瀏覽器交給他的憑證去passport.com驗證憑證是否有效，從而判斷使用者是否登入成功。
第四步：登入成功，瀏覽器與**之間進行正常的訪問。
下面就以耶魯大學研發的cas為分析依據，分析其工作原理。首先看一下最上層的專案部署圖：
部署專案時需要部署乙個獨立的認證中心（cas.qiandu.com），以及其他n個使用者自己的web服務。
認證中心：也就是cas.qiandu.com，即cas-server。用來提供認證服務，由cas框架提供，使用者只需要根據業務實現認證的邏輯即可。
使用者web專案：只需要在web.xml中配置幾個過濾器，用來保護資源，過濾器也是cas框架提供了，即cas-client，基本不需要改動可以直接使用。
上圖是3個登入場景，分別為：第一次訪問www.qiandu.com、第二次訪問、以及登入狀態下第一次訪問mail.qiandu.com。
下面就詳細說明上圖中每個數字標號做了什麼，以及相關的請求內容，響應內容。
標號1：使用者訪問經過他的第乙個過濾器（cas提供，在web.xml中配置）authenticationfilter。
過濾器全稱：org.jasig.cas.client.authentication.authenticationfilter
主要作用：判斷是否登入，如果沒有登入則重定向到認證中心。
首先可以看到我們請求www.qiandu.com，之後瀏覽器返回狀態碼302，然後讓瀏覽器重定向到cas.qiandu.com並且通過get的方式新增引數service，該引數目的是登入成功之後會要重定向回來，因此需要該引數。並且你會發現，其實server的值就是編碼之後的我們請求www.qiandu.com的位址。
標號3：瀏覽器接收到重定向之後發起重定向，請求cas.qiandu.com。
標號4：認證中心cas.qiandu.com接收到登入請求，返回登陸頁面。
上圖就是標號3的請求，以及標號4的響應。請求的url是標號2返回的url。之後認證中心就展示登入的頁面，等待使用者輸入使用者名稱密碼。
標號5：使用者在cas.qiandu.com的login頁面輸入使用者名稱密碼，提交。
標號6：伺服器接收到使用者名稱密碼，則驗證是否有效，驗證邏輯可以使用cas-server提供現成的，也可以自己實現。
上圖就是標號5的請求，以及標號6的響應了。當cas.qiandu.com即csa-server認證通過之後，會返回給瀏覽器302，重定向的位址就是referer中的service引數對應的值。後邊並通過get的方式挾帶了乙個ticket令牌，這個ticket就是st（數字3處）。同時會在cookie中設定乙個castgc，該cookie是**cas.qiandu.com的cookie，只有訪問這個**才會攜帶這個cookie過去。
cookie中的castgc：向cookie中新增該值的目的是當下次訪問cas.qiandu.com時，瀏覽器將cookie中的tgc攜帶到伺服器，伺服器根據這個tgc，查詢與之對應的tgt。從而判斷使用者是否登入過了，是否需要展示登入頁面。tgt與tgc的關係就像session與cookie中sessionid的關係。
tgt：ticket granted ticket（俗稱大令牌，或者說票根，他可以簽發st）
tgc：ticket granted cookie（cookie中的value），存在cookie中，根據他可以找到tgt。
st：service ticket （小令牌），是tgt生成的，預設是用一次就生效了。也就是上面數字3處的ticket值。
標號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有效。
至此，第一次訪問的整個流程結束，其中標號8與標號9的環節是通過**呼叫的，並不是瀏覽器發起，所以沒有擷取到報文。
上面以及訪問過一次了，當第二次訪問的時候發生了什麼呢？
標號11：使用者發起請求，訪問www.qiandu.com。會經過cas-client，也就是過濾器，因為第一次訪問成功之後www.qiandu.com中會在session中記錄使用者資訊，因此這裡直接就通過了，不用驗證了。
標號12：使用者通過許可權驗證，瀏覽器返回正常資源。
標號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：認證成功之後就反正用想要訪問的資源了。
至此，cas登入的整個過程就完畢了，以後有時間總結下如何使用cas，並運用到專案中。
下面是 cas 最基本的協議過程：
基礎協議圖
如 上圖： cas client 與受保護的客戶端應用部署在一起，以 filter 方式保護 web 應用的受保護資源，過濾從客戶端過來的每乙個 web 請求，同 時， cas client 會分析 http 請求中是否包含請求 service ticket( st 上圖中的 ticket) ，如果沒有，則說明該使用者是沒有經過認證的；於是 cas client 會重定向使用者請求到 cas server （ step 2 ），並傳遞 service （要訪問的目的資源位址）。 step 3 是使用者認證過程，如果使用者提供了正確的 credentials ， cas server 隨機產生乙個相當長度、唯
一、不可偽造的 service ticket ，並快取以待將來驗證，並且重定向使用者到 service 所在位址（附帶剛才產生的 service ticket ） ,並為客戶端瀏覽器設定乙個 ticket granted cookie （ tgc ）； cas client 在拿到 service 和新產生的 ticket 過後，在 step 5 和 step6 中與 cas server 進行身份核實，以確保 service ticket 的合法性。
在該協議中，所有與 cas server 的互動均採用 ssl 協議，以確保 st 和 tgc 的安全性。協議工作過程中會有2 次重定向的過程。但是 cas client 與 cas server 之間進行 ticket 驗證的過程對於使用者是透明的（使用 httpsurlconnection ）。
CAS單點登入原理
之前我們談了如何關於單點登入的一些概述，講到了當跨網域名稱單點登入時，cas的設計具有參考價值，那麼這篇就該談談cas的具體原理了。cas指的是apereo的cas開源專案，三個字母分別是是central authentication service的首字母縮寫。git 官方文件 截止目前版本已經更...
CAS單點登入原理
基於cookie的單點登入核心原理 將使用者名稱密碼加密之後存於cookie中，之後訪問 時在過濾器 filter 中校驗使用者許可權，如果沒有許可權則從cookie中取出使用者名稱密碼進行登入，讓使用者從某種意義上覺得只登入了一次。該方式缺點就是多次傳送使用者名稱密碼，增加被盜風險，以及不能跨域。...
cas單點登入 SSO 的實現原理
單點登入sso single sign on 說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型 裡使用得非常頻繁，例如像阿里巴巴這樣的 在 的背後是成百上千的子系統，使用者一次操作或交易可能涉及到幾十個...