CAS 与.net 集成的 “循环重定向”问题分析

转自:http://www.cnblogs.com/xingshao/archive/2011/09/29/2195746.html

近期的一个项目,项目包含了若干的子系统,因为人员配备的原因,项目会包含不同开发语言编写〔java、.net〕的几个子系统。项目从企业应用集成的角度进行架构,除了在应用层面上的“业务流程整合”之外。还有一个就是“身份认证”层面上的集成,身份认证的整合应用了CAS (Central Authentication Service),它是Yale 大学的 ITS 开发的一套 JAVA 实现的开源的SSO(single sign-on)的服务。
Cas的部署、实现在java项目系统中都很顺利的架设,实现了。但是在.net子系统中遇到了问题,.net下的集成是我今天要说的。
.net集成之初,参考了官上的范例(http://www.jasig.org/cas),它也提供.net客户端的源码下载。但是在调试的时候,出现了“循环请求验证”的现象,Ie的现象是“一直登录”,火狐下直接提示“循环访问”一类的错误。
首先在google直接找解决方法,但是遗憾的是并没有直接解决类似问题的信息。有几篇文章提到了这个现象,但是并没有提出解决方案,msdn中有这个问题,但是回复者都是三言两语,没有详细的解决方案,有的回答说“官网提供的是个半成品”。无语..暂且信之吧。
问题总是要解决的,以前没有实际使用过这个东西,所以还是从头开始吧,googel了一些cas的知识,对cas的机制,应用过程进行了解。
(具体知识详见 http://linliangyi2007.iteye.com/blog/165310说的很通俗〕。
Cas .net版本的客户端.是结合了asp.net自身的forms认证实现认证的。它是通过编写一个httpModel进行拦截,通过对客户端票据〔ticket〕的检查来实现对每一次请求的过滤,进而达到对功能页面的控制。首先在web.config中要配置一系列的cas服务端的参数信息,直接贴出

.net 自己的Forms认证这的配置也很重要,

最后就是httpModel的配置了

至此cas的基础配置完成了,但是这是不够的,这个的配置并没有错,但是实际运行中就会出现上述的“循环验证”的问题,通过分析代码,发现循环重定向到login页面的原因是每一次的验证都是失败,票据丢失,会话状态丢失。这个是引起循环重定向的直接凶手,

请求系统页面–>httpModel重定向–>cas登录页–>登录后的系统页面–>httpModel验证ticket失败–>重定向登录cas

这个过程周而复始,那么问题的核心在那呢?.“httpModel验证失败”,这个是整个问题过程中的核心,通过调试,最终也确定了导致失败的最终代码段。
httpModel

没有发现票据,也就是说票据实失效引起的cas 认证的重定向登录,那么是谁引起的ticket的失效呢?.最终排除了cas客户端和服务端的问题,也就是说cas 配置是正确的,??那是什么引起最初的“循环重定向”现象呢。“Asp.net forms 验证下的session失效”,问题由cas踢给.net自己的问题。最终问题再次转移了,变成了“在.net下,session失效的问题”,但是也看到了曙光,因为这个问题googel一下.会有太多的信息供你浏览。同时,我发现我被“java 、cas”这样的词误导了。基于.net的cas集成本身并不全是“cas”的问题,.net也是整合的一部分。

直接增加配置:

1、启用会话状态,
2、开始asp.net状态服务〔确保会话的持久,不在莫名其妙的失效。〕
3、对一些系统的页面进行页面缓存禁用,因为有几次..缓存的页面又一次误导了,让我以为cas的认证有问题。

通过解决asp.net的会话失效问题,发现应用cas后的“循环重定向”问题没有了。

最后要说一下cas的“登出”操作,“登出”必须要.net forms登出和 cas的服务端登出结合。一定要先将服务端会话Abandon,然后在对cookie进行过期操作。最后清清除cas服务端的验证票据。

至此,cas .net集成的问题彻底解决。本文强调的其实并不是解决“cas .net集成”这个现象,而是在解决这个现象的过程。在开发过程中,所有遇到的技术问题并不可怕,可怕的是你不知道如何去分析、分解问题,“大而化小,小而化了”才是解决问题的精髓。之所以说解决不了的问题,是因为你没有掌握分析、解决问题所必要的基础信息,比如“相关的领域知识”、涉及的技术特点。如果碰到了解决不了的问题,那肯定是在领域知识方面有欠缺,致使你不能分析、不能分解。