CAS認證（1）：流程詳解

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

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

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

在CAS中MVC的控制主要是使用的spring MVC來實作的。但是，在登入過程中，因為有點類似于工作流的性質，是以，采用了一個輕量級的工作流架構，就是spring 的weflow。下面，我們就CAS如何采用webflow控制登入流程進行分析。

想深入了解webflow工作原理的讀者需要參考官方的webflow2.21版本的reference。

好了，話不多說，開始CAS認證流程之旅。

這裡進行的處理就是将使用者的請求重定向到CAS認證中心的 /login 路徑下。在上一章中，我們已經知道，該路徑我們是由 名為 CAS 的servlet，也就是org.jasig.cas.web.init.SafeDispatcherServlet 進行處理的。我們進入該servlet看一下他是如何進行處理的。

進入該servlet中，我們看到，他繼承自 HttpServlet，也就是說他隻是一個普通的servlet。該servlet持有一個DispatcherServlet 屬性delegate。這同struts的處理方式如出一轍。都是通過一個代理類來進行處理請求的。

該類的初始化也僅僅是調用代理類delegate的初始化。Service函數很僅僅是調用delegate的service函數。

看來，DispatcherServlet類才是處理請求的關鍵類。我們看到DispatcherServlet類的完整路徑是

org.springframework.web.servlet.DispatcherServlet

這裡，也就是将請求交給了spring MVC處理了。（關于spring mvc，參考我其他的關于spring 的源碼分析文章）。

Spring MVC核心配置檔案是cas-servlet.xml。在該檔案中，webflow将與springMVC進行內建。

這裡有一個問題，就是spring何時開始加載cas-servlet.xml檔案的呢？

原來，在初始化DispatcherServlet的時候，會自動加載 servlet-name+“-servlet.xml”檔案。是以，cas-servlet.xml是自動加載的，不需要在配置檔案進行配置。（參見關于springMVC的文章）

交給spring MVC之後，spring MVC又将請求交給了 webflow處理。下面是webflow同spring MVC的結合：

在該檔案中，我們可以看到上面的配置項。這就是将webflow架構作為spring MVC的一個節點來進行配置。

webflow:flow-registry節點就是注冊了一個webflow流程，該流程的入口，也就是ID=“login”。這樣，交給springMVC的請求路徑如果是login的，則有springMVC交給webflow處理。

在webflow中，會定義一些視圖，這些視圖都是以view=”XXX”的形式存在的。那麼XXX又是如何找到對應的頁面呢？？看flow-builder-services節點，我們會發現有個view-factory-creator屬性，該屬性就定義了視圖解析工廠。

該視圖解析工廠是由視圖解析器組成的。這裡隻定義了一個視圖解析器，就是viewResolvers。該視圖解析器是springFramework中的ResourceBundleViewResolver的一個執行個體，該類可以通過basenames屬性，找到value值對應的properties屬性檔案，該檔案中式類似ke=values類型的内容，正是該檔案将jsp檔案映射成視圖名稱。

至此，springMVC與webflow已經內建完畢。

在WEB-INF檔案夾下的login-webflow.xml是登陸流程的主要配置檔案。在該檔案中，定義了使用者登入的整個處理流程。

首先，配置檔案中的 on-start标簽定義了使用者第一次進入流程中的預處理動作。該标簽對應spring中的id為initialFlowSetupAction的bean。檢視該bean（InitialFlowSetupAction）的代碼。該類需要繼承自AbstractAction，AbstractAction方法是org.springframework.webflow.action包中的類。是webflow中的基礎類。該類中的doExecute方法是對應處理業務的方法。就猶如servlet中的service方法一樣。該方法的參數是RequestContext對象，該參數是一個流程的容器。該方法從request中擷取TGT，并且建構一個臨時的service對象（不同域注冊的service，詳情見接入系統管理）。并且，将TGT和service放在FlowScope作用域中。

流程的初始化完畢之後，就開始一系列的判斷了。也就是進入decision-state節點。這些節點是依次執行的。

對應的dicision-state走完之後，如果不存在TGT，其實就會進入voiwLoginForm節點。該節點是一個view-state類型的，這也就是說明該節點是一個頁面，view=“casLoginView”屬性定義了該view對應的頁面是“casLoginView”。這個視圖會被spring的視圖解析器解析成/WEB-INF/view/jsp/default/ui/casLoginView.jsp頁面。使用者這時候就能看到一個登陸界面了。

需要注意的是，使用者看到的登入界面中，會有hidden類型的一個lt參數：

<inputtype="hidden" name="lt"value="${flowExecutionKey}" />

該參數可以了解成每個需要登入的使用者都有一個流水号。隻有有了webflow發放的有效的流水号，使用者才可以說明是已經進入了webflow流程。否則，沒有流水号的情況下，webflow會認為使用者還沒有進入webflow流程，進而會重新進入一次webflow流程，進而會重新出現登入界面。

使用者點選登入之後，送出到realSubmit節點。該節點執行的是authenticationViaFormAction.submit方法，在該方法中，将會驗證使用者的認證資訊是否正确。驗證成功之後，跳轉到sendTicketGrantingTicket,在這裡，将生成TGT，然後，進入serviceCheck，在serviceCheck中，将會驗證flowScope作用域中是否存在service，如果存在，則進入generateServiceTicket，否則進入登入成功頁面。在generateServiceTicket中，也将生成ST，同時檢查是否有警告資訊，然後進行重定向到使用者最開始請求的位址。

至此，springMVC與webflow整合以及登入整個流程已經講解完畢。

這裡講解的比較粗略。後續可能會較詳細的寫一下webflow的工作原理。另外，如果對于自定義登入流程如何處理，将會在特殊場景的解決方案中給出。