什麼是單點登入(SSO)

單點登入主要用於多系統整合，即在多個系統中，使用者只需要到一箇中央伺服器登入一次即可訪問這些系統中的任何一個，無須多次登入。

單點登入（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。

web系統如何實現單點登入

目前已經有了成熟的單點登入實現方案，比如CAS，我們只要在web系統中應用單點登入方案CAS即可。(主要涉及到註冊登入驗證等模組的改動)

什麼是CAS

CAS (Central Authentication Service)   是耶魯 Yale 大學發起的一個java開源專案，旨在為 Web應用系統提供一種可靠的 單點登入 解決方案（ Web SSO ）， CAS 具有以下特點：

1、   開源的企業級單點登入解決方案；

2、   CAS Server 為需要獨立部署的 Web 應用----一個獨立的Web應用程式(cas.war)。 ；

3、   CAS Client 支援非常多的客戶端 ( 指單點登入系統中的各個 Web 應用 ) ，包括 Java, .Net, PHP, Perl, 等。

CAS在2004年12月成為Jasig專案，所以也叫JA-SIG CAS。 

CAS 原理

CAS Server

CAS Client 

CAS相關詞彙和概念

(後面程式碼小節會詳細介紹，這裡初步瞭解即可)

TGC(ticket-granting cookie)-- ------- 授權的票據證明，由 CAS Server 通過 SSL 方式傳送給終端使用者；

KDC( Key Distribution Center ) ---------- 金鑰發放中心；

ST (Service ticket) --------- 服務票據， 由 KDC 的 TGS 發放， ST   只能被嘗試驗證一次。 任何一臺 Workstation 都需要擁有一張有效的 Service Ticket 才能訪問域內部的應用 (Applications) 。 如果能正確接收 Service Ticket ，說明在 CASClient-CASServer 之間的信任關係已經被正確建立起來，通常為一張數字加密的證書；

Ticket Granting tieckt(TGT) --------- 票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交 Credentials （憑證或身份認證資訊 ) ；

Authentication Service (AS) --------- 認證服務，索取 Crendential ，發放 TGT ；

Ticket-Granting Service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST 。

CAS協議和工作流程

下圖是 CAS 最基礎協議：

1 、 CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求， CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，如果沒有，則說明當前使用者尚未登入，於是將請求重定向到指定好的 CAS Server 登入地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登入成功過後轉回該地址。使用者在第 3 步中輸入認證資訊，如果登入成功， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並快取以待將來驗證，之後系統自動重定向到 Service 所在地址，併為客戶端瀏覽器設定一個 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新產生的 Ticket 過後，在第 5 ， 6 步中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。

2 、在該協議中，所有與 CAS 的互動均採用 SSL 協議確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向的過程，但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於使用者是透明的。

3 、 CAS 如何實現 SSO

當用戶訪問另一服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：

1) 如果 User 的持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；

2) 如果 TGC 失效，那麼使用者還是要重新認證 ( 走基礎協議圖的 Step3) 。

cas的驗證流程

1.      使用者瀏覽受系統保護的URL。

2.      CAS Client服務端收到請求，Filter攔截該請求，在Filter中判斷該使用者是否已經登陸，如果已經登陸，就直接進入系統，否則，將請求轉發到CAS Server服務端的LoginURL。

3.      在LoginURL中會獲取到使用者的Cookie，檢驗使用者是否已經在其他相關使用SSO的系統登陸成功。如果已經在其他的系統登陸了，則將請求轉回 CAS Client，並且帶回一個ticket, CAS Client再次傳送請求到ValidateURL。否則，系統提示使用者輸入ID和PASSWORD。

4.      提交後請求到ValidateURL，CAS Server驗證ticket的有效性。然後返回結果給CAS Client。如果ticket有效，則CAS Client應讓該使用者瀏覽受保護的資源。否則，重定向到登陸頁面，提示使用者輸入ID和PASSWORD。

5.      校驗ID和Password是否匹配。如不匹配，再次要求使用者輸入ID和PASSWORD。否則，CAS Server記錄使用者登陸成功。並向瀏覽器回送Cookie，記錄使用者已經登陸成功。如果瀏覽器不支援Cookie，則無法實現單點登陸。

使用者訪問流程流程例項

使用者第一次訪問一個CAS 服務的客戶web 應用時（例如訪問URL ：http://192.168.1.90:8081/web1 ），部署在客戶web 應用的cas AuthenticationFilter ，會截獲此請求，生成service 引數，然後redirect 到CAS 服務的login 介面，url為https://cas:8443/cas/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F ，認證成功後，CAS 伺服器會生成認證cookie ，寫入瀏覽器，同時將cookie 快取到伺服器本地，CAS 伺服器還會根據service 引數生成ticket,ticket 會儲存到伺服器，也會加在url 後面，然後將請求redirect 回客戶web 應用，url 為http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 。

這時客戶端的AuthenticationFilter 看到ticket 引數後，會跳過，由其後面的TicketValidationFilter 處理，TicketValidationFilter 會利用httpclient 工具訪問cas 服務的/serviceValidate 介面, 將ticket 、service 都傳到此介面，由此介面驗證ticket 的有效性，TicketValidationFilter 如果得到驗證成功的訊息，就會把使用者資訊寫入web 應用的session裡。

至此為止，SSO 會話就建立起來了，以後使用者在同一瀏覽器裡訪問此web 應用時，AuthenticationFilter 會在session 裡讀取到使用者資訊，所以就不會去CAS 認證，如果在此瀏覽器裡訪問別的web 應用時，AuthenticationFilter 在session 裡讀取不到使用者資訊，會去CAS 的login 介面認證，但這時CAS 會讀取到瀏覽器傳來的cookie ，所以CAS 不會要求使用者去登入頁面登入，只是會根據service 引數生成一個ticket ，然後再和web 應用做一個驗證ticket 的互動。

程式碼層次如何實現CAS

知道工作原理和流程之後我們來看看應該怎麼在程式碼上實現CAS

一般來說，我們寫Web應用只需要熟悉這幾個Filter就可以了，如果不需要https連線，連第一個也不用熟悉。但是有人肯定會想，這些 Filter怎麼和我的資料庫聯絡起來呢？不用著急，這些Filter並不直接處理使用者的認證，也不直接處理使用者的授權，而是把它們交給了認證管理器和決 策管理器。

對於這兩種管理器，那也是不需要我們寫程式碼的，Acegi也提供了現成的類。那麼大家又奇怪了：又是現成的，那怎麼和我的資料庫關聯起來呢？別 著急，其實這兩個管理器自己也不做事，認證管理器把任務交給了Provider，而決策管理器則把任務交給了Voter，如下圖：

現在我要告訴你們，這裡的Provider和Voter也是不需要我們寫程式碼的。不要崩潰，快到目標了。Acegi提供了多個Provider 的實現類，也就是說CAS的認證方式有很多種，我們可以到資料庫檢索一條使用者帳號資訊，也可能在 XML 檔案中檢索使用者密碼， 對於很多種方式，CAS 均提供一種靈活但同一的介面 / 實現分離的方式， CAS 究竟是用何種認證方式，可以由我們自己來決定，也就是，這個認證的實現細節可以自己定製和擴充套件。例如如果我們想用資料庫來儲存使用者的認證資料，那麼我們就選擇DaoAuthenticationProvider。對於Voter，我們一般選擇 RoleVoter就夠用了，它會根據我們配置檔案中的設定來決定是否允許某一個使用者訪問制定的Web資源。

　　而DaoAuthenticationProvider也是不直接操作資料庫的，它把任務委託給了UserDetailService，如下圖：

而我們要做的，就是實現這個UserDetailService。說了這麼多總算是引出了我們開發中的關鍵，那就是我們要實現自己的UserDetailService，它就是連線我們的資料庫和Acegi的橋樑。UserDetailService的要求也很簡 單，只需要一個返回org.springframework.security.userdetails.User物件的 loadUserByUsername(String userName)方法。因此，怎麼設計資料庫都可以，不管我們是用一個表還是兩個表還是三個表，也不管我們是使用者-授權，還是使用者-角色-授權，還是用 戶-使用者組-角色-授權，這些具體的東西Acegi統統不關心，它只關心返回的那個User物件，至於怎麼從資料庫中讀取資料，那就是我們自己的事了。

反過來再看看上面的過程，我們發現，即使我們要做的只是實現自己的UserDetailService類，但是我們不得不在Spring中配置那一 大堆的Bean，包括幾個Filter，幾個Manager，幾個Provider和Voter，而這些配置往往都是重複的無謂的。好在Acegi 2.0也認識到了這個問題，所以，它設計了一個<http>標籤，讓Acegi的配置得到了簡化。

CAS的相關介面和處理邏輯

Ticket介紹

概念介紹

類和方法

CAS Ticket類圖 如下：

TicketGrantingTicket 的 grantServiceTicket方法
方法宣告：public synchronized ServiceTicket grantServiceTicket(final String id,final Service service, final ExpirationPolicy expirationPolicy, final boolean credentialsProvided)

方法描述:
 1：生成SerivceTicketImpl
 2：更新屬性：
this.previousLastTimeUsed = this.lastTimeUsed;
this.lastTimeUsed = System.currentTimeMillis();
this.countOfUses++;
 3：給service物件的principal屬性賦值
 4：將service物件放入map services
 

ServiceTicket 的 grantTicketGrantingTicket方法

方法宣告：
public TicketGrantingTicket grantTicketGrantingTicket(final String id, final Authentication authentication,final ExpirationPolicy expirationPolicy)
方法描述：在CAS3.3對CAS2.0協議的實現中，PGT是由ST簽發的，呼叫的就是ServiceTicket的grantTicketGrantingTicket方法。方法返回的TicketGrantingTicket物件，表徵的是一個PGT物件，其中的ticketGrantingTicket屬性的值是簽發ST的TGT物件。 


TicketGrantingTicket 的 expire方法
方法宣告：void expire()
方法描述：
在CAS的logout介面實現中，要呼叫TGT物件的expire方法，然後會在快取中清除此TGT物件。
expire方法的內容：迴圈遍歷 services 中的Service物件，呼叫其logoutOfService方法。具體Service實現類中的logoutOfService方法的實現，要通知具體的應用，客戶要退出。

TGT、ST、PGT、PT關係

認證相關的類和流程

Credentials 

AuthenticationHandler 

Principal 

CredentialsToPrincipalResolvers

AuthenticationMetaDataPopulators 

Authentication 

AuthenticationManager 

CentralAuthenticationService

cas server的介面

CAS 服務端總共對外定義了9 個介面，客戶端通過訪問這9 個介面與服務端互動，這9個介面為：

 /login

CAS 預設的登入處理流程圖如下:

說明：

1 ： InitialFlowSetupAction: 是流程的入口。用 request.getContextPath() 的值來設定 cookie 的 Path 值， Cookie 的 path 值是在配置檔案裡定義的，但這個 Action 負責將 request.getContextPath() 的值設定為 Cookie 的 path 值，這是在 cas 部署環境改變的情況下，靈活地設定 cookie path 的方式；把 cookie 的值以及 service 引數的值放入 requestContext 的 flowscope 裡。

2 ： GenerateServiceTicketAction 此 Action 負責根據 service 、 GTC cookie 值生成 ServiceTicket 物件， ServiceTicket 的 ID 就是返回給客戶應用的 ticket 引數，如果成功建立 ServiceTicket ，則轉發到 WarnAction ，如果建立失敗，且 gateway 引數為 true ，則直接redirect 到客戶應用， 否則則需要重新認證。

3 ： viewLoginForm 這是登入頁面， CAS 在此收集使用者憑證。 CAS 提供的預設實現是 /WEB-INF/view/jsp/simple/ui/casLoginView.jsp 。

4 ： bindAndValidate 對應 AuthenticationViaFormAction 的 doBind 方法，該方法負責蒐集登入頁面上使用者錄入的憑證資訊（使用者名稱、密碼等），然後把這些資訊封裝到 CAS 內部的 Credentials 物件中。使用者在 casLoginView.jsp 頁面上點選提交後，會觸發此方法。

5:submit   對應 AuthenticationViaFormAction 的 submit 方法 , 如果 doBind 方法成功執行完， 則觸發 submit 方法，此方法負責呼叫centralAuthenticationService 的      grantServiceTicket 方法，完成認證工作，如果認證成功，則生成 TicketGrantingTicket 物件，放在快取裡， TicketGrantingTicket 的 ID 就是 TGC Cookie 的 value 值。

6 ： warn  CAS 提供了一個功能：使用者在一個 web 應用中跳到另一個 web 應用時， CAS 可以跳轉到一個提示頁面，該頁面提示使用者要離開一個應用進入另一個應用，可以讓使用者自己選擇。使用者在登入頁面 viewLoginForm 上選中了 id=”warn” 的複選框，才能開啟這個功能。

WarnAction 就檢查使用者有沒有開啟這個功能，如果開啟了，則轉發到showWarnView, 如果沒開啟，則直接redirect 到客戶應用。

7 ：SendTicketGrantingTicketAction 此Action 負責為response 生成TGC Cookie ，cookie 的值就是 AuthenticationViaFormAction 的submit 方法生成的 TicketGrantingTicket 物件的 ID 。

8 ： viewGenerateLoginSuccess 這是 CAS 的認證成功頁面。

第一次訪問Web 應用的流程走向圖如下:

已經登入web1 後，訪問web1 的資源（web1 沒有啟動session ），或訪問web2 的資源走向圖如下:

/logout

（ 對應實現類 org.jasig.cas.web.LogoutController ）

處理邏輯：
        1) removeCookie
       2) 在服務端刪除TicketGrantingTicket 物件（此物件封裝了cookie 的value 值）
       3 ) redirect 到退出頁面，有2 種選擇：
          if(LogoutController 的followServiceRedirects 屬性為true 值，且url 裡的service 引數非空){
                redirect 到 sevice 引數標識的url
             }
          else{
             redirect 到內建的casLogoutView （cas/WEB-INF/view/jsp/default/ui/casLogoutView.jsp ），如果url 裡有url 引數，則此url 引數標識的連結會顯示在casLogoutView 頁面上。
           }

/serviceValidate

（對應實現類 org.jasig.cas.web.ServiceValidateController ）

 處理邏輯：  
  如果service 引數為空或ticket 引數為空，則轉發到failureView （/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationFailure.jsp ）
 驗證ticket 。以ticket 為引數，去快取裡找ServiceTicketImpl 物件，如果能找到，且沒有過期，且ServiceTicketImpl 物件對應的service 屬性和service 引數對應，則驗證通過，驗證通過後，請求轉發至casServiceSuccessView （cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp ），驗證不通過，則轉發到failureView 。

CAS CLIENT配置引數

CAS安全性

CAS 的安全性從 v1 到 v3 ，都很依賴於 SSL ，所有與 CAS 的互動均採用 SSL 協議，確保，ST 和 TGC 的傳輸安全性。

TGC 安全性

ST 安全性

實現單點登入的開發流程

通過上面的學習我們已經對單點登入以及CAS有了一定的瞭解，那麼我們怎麼入手搭建叢集的單點登入呢?

步驟如下

搭建部署cas server

首先我們肯定是要下載cas server的程式碼，然後進行使用者名稱密碼驗證認證方式的選型，選型結束後進行相應配置以及登入介面的修改等等。

然後把cas server的war包釋出到伺服器上，執行即可。

web專案中整合cas client

cas server搭建完成後登入認證模組已經有了，那麼怎麼跟我們的web專案關聯起來呢? 這就需要在web 專案中整合cas的client客戶端了，集成了之後，對cas client的配置檔案進行配置，對應到cas server的地址，這樣它們就能聯絡起來了。 

cas server認證方式的選型

我們之前已經說過了cas支援很多種認證方式，我們即可把使用者名稱密碼寫在xml中，然後cas來讀取之後跟使用者輸入的帳號密碼對比，也可以把使用者名稱密碼存在資料庫中。

目前cas提供給了以下認證方式:

GENERIC

JAAS

JDBC--關係型資料庫

MongoDB--非關係資料庫

有些認證方式對於web開發，基本上不太好用或者不常用，因為他們的配置太不靈活或者太專業化。在此之所以列舉了那麼多關於cas的認證處理器，主要為了讓大家知道，cas支援這種認證方式。比如現在新浪微博就對外開通了oauth認證介面，如果哪一天公司進行戰略轉形，希望用cas接新浪微博賬號認證，那麼就可以直接在此基礎上進行好好研究。

一般LDAP和資料庫比較常用，我們接下來會著重講這兩種的運用。