CAS認證（3）：驗證使用者資訊

内部邀請碼：C8E245J （不寫邀請碼，沒有現金送）

國内私募機構九鼎控股打造，九鼎投資是在全國股份轉讓系統挂牌的公衆公司，股票代碼為430719，為“中國PE第一股”，市值超1000億元。 

------------------------------------------------------------------------------------------------------------------------------------------------------------------

這篇文章主要是對使用者送出的使用者名及密碼等進行認證。該過程相對簡單一些，但我們更多的是學習他的設計思路。

上一篇文章中，我們在authenticationViaFormAction 中的submit方法中TGT的生成是通過

方法來生成的。

在該方法中，參數credentials就是對使用者送出的認證資訊的封裝，該對象主要就是簡單的包含了使用者名和密碼等。

那我們進詳細的看一看該方法中邏輯行為吧。

CentralAuthenticationService 接口是CAS中的核心接口，他定了CAS中核心的一些行為。

createTicketGrantingTicket

該方法主要是驗證認證資訊，生成TGT。

grantServiceTicket

該方法主要是生成ST

validateServiceTicket

該方法主要是驗證ST有效性。

destroyTicketGrantingTicket  

該方法主要是銷毀TGT

delegateTicketGrantingTicket 

該方法主要是代理票據的生成

可以看到，這些都是認證流程中的核心方法。

該接口的預設實作是 CentralAuthenticationServiceImpl 。我們先來看一下createTicketGrantingTicket方法

      這裡可以看到， 代碼中先是通過調用this.authenticationManager.authenticate方法對credentials進行驗證。并傳回驗證結果 authentication。在這個過程中，如果驗證出現問題，是會抛出異常的。

   然後通過建構一個TicketGrantingTicketImpl 對象來形成TGT對應資訊。之前說過，TGT是以cookie的形式存在的。那是在用戶端浏覽器中存在形式。在server端測試存在一個ticketGrantTicket對象的。這一點同session與jessionid的關系非常像。生成的tgt存儲在ticketRegistry中。然後傳回TGT。這裡先不對ticket的生成和管理進行講解，後面會詳細的說明，這裡繼續講解認證的過程。

我們要看一下該方法中的認證是怎麼樣的，首先要看一下這個類的結構是什麼樣的。CAS中對象的管理主要是通過spring的IOC實作的。關于認證的bean的配置主要是在deployConfigContext.xml中定義的。在該配置檔案中

我們可以看到，在manager中，主要有兩個list的屬性：credentialsToPrincipalResolvers和authenticationHandlers

其中authenticationHandlers list主要是用來做認證用的。該list中所有的bean都需要實作AuthenticationHandler接口中的authenticate方法。使用者送出認證請求之後，要滿足該list中任意認證的條件才算是認證成功。每一個bean都可以配置自己的驗證方式。是以，對于有多個認證方式的應用的時候，在這裡自行組裝認證條件就可以。

credentialsToPrincipalResolverslist屬性主要是在驗證成功之後，将使用者屬性提取出來。并傳遞到接入系統中。如果使用者資料存儲在存在多個資料源中，則在這裡可以寫多個屬性提取器，分别将使用者的屬性提取出來，然後處理後傳遞給用戶端。

下面我們就源碼進行分析。檢視AuthenticationManagerImpl.authenticateAndObtainPrincipal方法：

這裡可以看到，就是對authenticationHandlers 進行周遊，如果通過認證，則break。

這裡對credentialsToPrincipalResolvers進行解析，一旦擷取到使用者的屬性，則建構了一個新的Pair對象，該對象中有認證的類和使用者屬性。

下面，我們就深入org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler看一下該類是如何對使用者進行認證的。

這裡，我對這個類簡單看一下，credentials是對認證請求的簡單封裝。當然可以擷取到使用者名和密碼。然後将密碼進行加密之後，同資料庫查詢的結果進行比對。

CAS中，對于資料庫的操作主要都是使用spring的JdbcTemplate 來操作的。這裡也不例外。 

這裡的業務邏輯比較簡單。在回頭看看這裡的實作。他将能分離出來的元件全都獨立出來。比如說密碼加密算法。資料源，查詢語句等。任何元件的更改不會對其他的元件産生影響。這就是面向對象的好處，這就是使用spring ioc的好處。