第三部分：实现 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了。
待续...
