CAS實現SSO單點登陸原理

安全性：

用戶只須在cas錄入用戶名和密碼，以後經過ticket綁定用戶，在cas客戶端與cas校驗是經過ticket，並不會在網上傳輸密碼，因此能夠保證安全性，密碼不被竊取

原理：１個cookie+Ｎ個session

ＣＡＳ建立cookie在全部應用中登陸時cas使用,各應用經過在ＩＥ建立各自的session來標識應用是否已經登陸。

Cookie:在cas爲各應用登陸時使用，實現了只須一次錄入用戶密碼

Session:各應用會建立本身的session表示是否登陸

登陸

１.  CAS　登陸時處理：

第一步：cas往瀏覽器增長cookie（ＴＧＣ）

CAS向瀏覽器送回一個所謂的「內存cookie」。這種cookie並非真的保存在內存中，而只是瀏覽器一關閉，cookie就自動過時。這個cookie稱爲「ticket-granting cookie」，用來代表用戶已經成功地登陸。

這個Cookie是一個加密的Cookie，其中保存了用戶登陸的信息。用於之後其它應用客戶端登陸。

第二步：cas同時建立一個ticket重定向到原來的cas客戶端

認證成功後，CAS服務器建立一個很長的、隨機生成的字符串，稱爲「Ticket」。隨後，CAS將這個ticket和成功登陸的用戶，以及服務聯繫在一塊兒。這個ticket是一次性使用的一種憑證，它只對登陸成功的用戶及其服務使用一次。使用過之後馬上失效。

２.  Cas 客戶端應用Ａ的處理

第一步：收到ticket後，向cas提交驗證ticket

Cas客戶端收到ticket以後，應用程序須要驗證ticket。這是經過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是CAS服務器提供的。CAS經過校驗路徑得到了ticket以後，經過內部的數據庫對其進行判斷。若是判斷是有效性，則返回一個NetID給應用程序。隨後CAS將ticket做廢，而且在客戶端留下一個cookie。（誰來建立cookie？），

第二步：ticket驗證後建立session

       　　　之後登陸此應用時，沒有ticket，但ＩＥ能提供session,從session中取得CASReceipt,並驗證若是有效說明已經在此應用認證過，容許訪問此應用，

       到此爲止，ＣＡＳ會記錄用戶已在應用Ａ已經登陸

３.  用戶登陸到應用Ｂ是如何處理

  用戶進入應用Ｂ時，首先仍然會重定向到CAS服務器。不過此時CAS服務器再也不要求用戶輸 入用戶名和密碼，而是首先自動尋找Cookie，根據Cookie中保存的信息，進行登陸。而後，CAS一樣給出新的ticket重定向應用Ｂ給cas驗證（流程同應用Ａ驗證方式），若是驗證成功則應用Ｂ建立session記錄CASReceipt信息到session中，之後憑此session登陸應用Ｂ。

到此爲止，ＣＡＳ會記錄用戶已在應用A和應用B進行登陸，可是當用戶在應用B退出cas登陸時，要通知應用Ａ進行退出，如何通知應用Ａ呢？

      

登出

　　　

　　CAS server接受請求後，會檢測用戶的TCG Cookie，把對應的session清除，同時會找到全部經過該TGC sso登陸的應用服務器URL提交請求,全部的回調請求中，包含一個參數logoutRequest,內容格式以下：

<samlp:LogoutRequest ID="[RANDOM ID]" Version="2.0" IssueInstant="[CURRENT DATE/TIME]">
<saml:NameID>@NOT_USED@</saml:NameID>
<samlp:SessionIndex>[SESSION IDENTIFIER]</samlp:SessionIndex>
</samlp:LogoutRequest>

全部收到請求的應用服務器application會解析這個參數，取得sessionId，根據這個Id取得session後，把session刪除。
這樣就實現單點登出的功能。
 

客戶端實現：

首先，要實現single sign out在 應用服務器application端的web.xml要加入如下配置

<filter>
   <filter-name>CAS Single Sign Out Filter</filter-name>
   <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>

<filter-mapping>
   <filter-name>CAS Single Sign Out Filter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>

<listener>
    <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>

注：若是有配置CAS client Filter,則CAS Single Sign Out Filter 必需要放到CAS client Filter以前。

配置部分的目的是在CAS server回調全部的application進行單點登出操做的時候，須要這個filter來實現session清楚。

 

 服務器端實現

 

　已經登陸的應用會在服務器端保存，因此服務端分別對各個應用發送http請求進行session清除操做。

 

看了下面的瀏覽器cookie變化，會對cas有更深的理解

下載個httpwatch監控一下cookie的變化

客戶端消息流程

1.       第一次訪問http://localhost:8080/a,

CLIENT：沒票據且SESSION中沒有消息因此跳轉至CAS

CAS：拿不到TGC故要求用戶登陸

  

2.       認證成功後回跳

CAS：經過TGT生成ST發給客戶端，客戶端保存TGC，並重定向到http://localhost:8080/a

CLIENT：帶有票據因此不跳轉只是後臺發給CAS驗證票據（瀏覽器中沒法看到這一過程）

3.       第一次訪問http://localhost:8080/b

CLIENT：沒票據且SESSION中沒有消息因此跳轉至CAS

CAS：從客戶端取出TGC，若是TGC有效則給用戶ST並後臺驗證ST，從而SSO。【若是失效重登陸或註銷時，怎麼通知其它系統更新SESSION信息呢？？TicketGrantingTicketImpl類grantServiceTicket方法裏this.services.put(id,service);可見CAS端已經記錄了當前登陸的子系統】

4.       再次訪問http://localhost:8080/a

CLIENT：沒票據可是SESSION中有消息故不跳轉也不用發CAS驗證票據，容許用戶訪問