第三部分：實現 ASP.NET WebForm Client
1. 下載.NET CAS client。
.NET CAS Client 下載地址：https://wiki.jasig.org/display/CASC/.Net+Cas+Client
下載“dotnet-client-1.0-Src.zip”並解壓縮。
2. 配置 CAS DotNetClient
以管理員身份啟動Visual Studio（目的為了隨后可以直接將網站發布到IIS），打開“DotNetCasClient.vs2010.sln”解決方案。
（1）項目“DotNetCasProxyDemoApp”暫時用不到，從解決方案中移除。
（2）將“DotNetCasClient”項目中“Properties”文件夾下的“AssemblyInfo.cs”刪除，將“AssemblyInfo.cs.tmpl”重命名為“AssemblyInfo.cs”。
（3）打開將“DotNetCasClient”項目中“Properties”文件夾下的“AssemblyInfo.cs”，將所有“$WCREV$”替換成“0”（或其它表示版本的數字）。
（4）將“ExampleWebSite”項目設置為啟動項。
（5）將“ExampleWebSite”項目根文件夾下的“web.config.sample”重命名為“web.config”
（6）打開“web.config”文件，找到“casClientConfig”節點，將“casServerLoginUrl”屬性設置為“https://192.168.0.123:8443/cas/login”，將“casServerUrlPrefix”屬性設置為“https://192.168.0.123:8443/cas/”，將“serverName”屬性設置為“http://localhost:3273/ExampleWebSite”。
說明：192.168.0.123是前面我們配置好的CAS服務器IP地址；“serverName”屬性中3273為運行該項目時IISExpress自動分配的端口號，如果項目發布到客戶端IIS上，建議將“serverName”屬性更改為“http://192.168.0.153/ExampleWebSite”，其中192.168.0.153為客戶端IP地址。注意：“serverName”屬性中網絡地址最后不要加“/”。
（7）從“web.config”文件中找到“authentication”節點，將“loginUrl”屬性設置為“https://192.168.0.123:8443/cas/login”，將“path”屬性設置為“/ExampleWebSite/”。
（8）保存全部修改，重新編譯解決方案。
3. 調試 CAS DotNetClient
（1）鼠標右擊“DotNetCasClient”項目根目錄下的“Default.aspx”，選擇“在瀏覽器中查看...”
（2）單擊“Authenticated Users Only”連接，系統自動重定向到CAS登錄頁面（如果IE有證書警告信息，直接點擊“繼續瀏覽此網站”），此時IE會報網頁有錯誤。
這是由於CAS中的一段腳本引起的。如圖所示，調試信息指出是“cas/js/cas.js”腳本出了問題。
（3）回到IP地址為“192.168.0.123”的服務器，以管理員身份編輯“%TOMCAT_HOME%\webapps\cas\js\cas.js”，滾動到文件最下方添加兩行代碼並保存。如圖所示：
（4）回到客戶端機器，重復步驟（1），這回IE不再報網頁有錯誤。
注意：每次運行項目時強烈建議清除IE緩存及Cookies，防止因IE緩存造成不必要的錯覺。
（5）在CAS登錄窗體中輸入用戶名和密碼，均為“admin”，此時會出現登錄異常，要么IE提示一遍一遍重新登錄，要么IE會出現“假死”現象。如果使用Chorme瀏覽器，你就會發現遭遇“重定向循環”問題了。
4. 解決CAS DotNetClient重定向循環問題
CAS DotNetClient重定向循環問題早就有人發現了，並且提出了各種解決辦法。通過檢索會發現最有幫助的就是博客園“邢少”的《CAS 與.net 集成的 “循環重定向”問題分析》一文。在這篇博文中，建議用戶直接增加配置：
<sessionState mode="StateServer" cookieless="UseCookies" timeout="36000"></sessionState>
其目的為：1、啟用會話狀態；2、開始asp.net狀態服務〔確保會話的持久，不在莫名其妙的失效。〕。
然而，通過對項目“DotNetCasClient”代碼的追蹤和分析發現，狀態信息是通過Cache存儲的，與sessionState的關系應該不大。本人認為該方法並不能解決問題。
通過在“DotNetCasClient\Validation\TicketValidator\AbstractUrlTicketValidator.cs”設置斷點，並通過F11逐步運行程序發現問題出在“基礎連接已經關閉: 未能為 SSL/TLS 安全通道建立信任關系。”
因此，提供如下修改方案：
（1）在Visual Studio中打開“CASDotNetClient”項目中的“\Utils\HttpUtil.cs”文件，添加如下命名空間：
using System.Net.Security; using System.Security.Authentication; using System.Security.Cryptography.X509Certificates;
（2）在HttpUtil類中增加如下方法：
internal static bool CheckValidationResult(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors) { return true; }
（3）在PerformHttpGet方法中添加驗證服務器證書回調自動驗證代碼，添加代碼后的PerformHttpGet方法如下：
internal static string PerformHttpGet(string url, bool requireHttp200) { string responseBody = null; //-- 以下新添加的代碼：驗證服務器證書回調自動驗證 ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(CheckValidationResult); //-- 以上為新添加的代碼 HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); using (HttpWebResponse response = (HttpWebResponse)request.GetResponse()) { if (!requireHttp200 || response.StatusCode == HttpStatusCode.OK) { using (Stream responseStream = response.GetResponseStream()) { if (responseStream != null) { using (StreamReader responseReader = new StreamReader(responseStream)) { responseBody = responseReader.ReadToEnd(); } } } } } return responseBody; }
（4）保存修改並重新生成解決方案。
5. 測試 CAS DotNetClient
（1）鼠標右擊“DotNetCasClient”項目根目錄下的“Default.aspx”，選擇“在瀏覽器中查看...”
（2）單擊“Authenticated Users Only”連接，系統自動重定向到CAS登錄頁面（如果IE有證書警告信息，直接點擊“繼續瀏覽此網站”）。
（3）輸入用戶名、密碼（均為“admin”，或均為“bob”），CAS自動完成登錄並重定向回原有網站。
至此，基於ASP.NET WebForm的CAS客戶端已經完全調試通過。下面就“重定向循環”做進一步討論討論
6. 深入討論DotNetClient重定向循環問題
這里提供兩篇我從網上搜到的解決辦法，並探討解決辦法存在的問題。
（1）HOWTO CASifying ASP.NET WebApp - ExampleWebsite
此文應該是官方網站上放出來的解決辦法，應該具有權威性。它提供的主要解決辦法就是讓CAS Server和CAS Client互相信任對方的證書，從而避免SSL因不信任證書造成重定向循環。然而實際情況確是IE根本不會信任用戶自己生成的證書，即便加入信任證書根列表也不行，造成“重定向循環”依然存在。
另外，此篇文章要求配置IIS支持SSL，其實根本沒有必要，IIS不配置SSL也可以正常運行。當然，為了安全起見，配置SSL也沒有什么壞處。
（2）博客園“邢少”的《CAS 與.net 集成的 “循環重定向”問題分析》一文
該文試圖從sessionState配置上解決問題，但從本人的實踐看來，“重定向循環”並未得到解決，“重定向循環”問題的本質還是SSL證書信任問題。
7. 關於DotNetClient注銷問題
關於DotNet注銷網上有很多介紹的材料。我這里就不再多說什么了。留下個鏈接供大家參考。《解釋CAS Logout問題》
為了便於查看，將《解釋CAS Logout問題》一文的主要內容放在下面便於查閱：
CAS Logout是一個非常費解的問題，我在這里簡單解釋一下：
假設有webapp1, webapp2, cas server，webapp1, webapp2均受cas server保護。
第1種不能logout的情況：
1）登錄了WebApp1，redirect到caserver，casserver認證后，再redirect到webapp1，ok！
2）http方式 lougout casserver1，即http://yale_casserver:8080/cas/lougout，顯示logout成功
3）訪問webapp2，還能訪問！這是非常正常的一種情況，因為你不通過https來注銷，casserver怎么“殺”掉它通過https發給你的TGC Cookie?
第2種不能logout的情況：
1）登錄了WebApp1，redirect到caserver，casserver認證后，再redirect到webapp1，ok！
2）https方式 lougout casserver1，即https://yale_casserver:8443/cas/lougout，顯示logout成功
3）訪問webapp1，還能訪問！訪問webapp2，不能訪問，重定向到casserver要求登錄！這也是非常正常的一種情況，因為你已經能夠訪問，你繼續可以繼續訪問，CASLogout不能阻止你訪問webapp1，它只能阻止你訪問webapp2，因為你已經被允許訪問webapp1，而webapp2則還沒有，如果你在(1)的時候，順帶也訪問webapp2，那么你的注銷將毫無作用了，CAS無法阻止你訪問這兩個webapp，因為你有Service Ticket。
如果你對此費解，那時因為你已為Logout就是退出系統，那我只能表示遺憾，因為CAS Logout的作用不是這樣，它的作用是阻止你繼續通過TGC（它簡單地清楚了IE的TGC Cookie）來獲取ST，阻止你獲取通向其他web應用的Ticket。
所以，用完webapp1的時候，注銷，然后再關閉掉IE就徹底Logout了。
待續...