CAS3.4 代理模式详细配置

版本

CAS服务器版本：3.4.2

CAS客户端for JAVA版本：3.1.10

 

前言

CAS3.4版本的资料在网上实在是少的可怜啊，幸亏官方网站所提供的资料帮助我完成了代理模式的配置，不过读E文真的很费劲。

 

在详细配置之前先说下对代理模式的认证，在网上查资料时看到有人说代理模式是服务于C/S架构的程序，还举例说什么看电影什么的，当然每个人都有不同的看法，不过我真的不很赞同以上的说法。

接下来我说下我对代理模式的简单认识，如有不妥可以拍砖。

 

代理：顾名思义，是代替别人去做一些事，那么在CAS的环境中，代理所要做的事情是代替一个APP去申请ticket（proxy ticket），先说B/S架构的用处：

在B/S架构的应用场景中，了解CAS运行原理的应该都知道，其实不用代理也是不影响应用程序整个环境的运行，只要每个应用程序实现了CAS Client，都会自动去CAS服务端申请票据，那么使用代理模式后会对APP带来什么样的改变呢？其实很简单，通过查看CAS客户端的源码就能知其所以然。  APP实现CAS客户端需要增加至少两个Filter，那么第一个就是认证Filter，在其Filter中有一个检查session中有没有Assertion对象，如果有则结束，则否会重定向到CAS服务器进行认证，认证后返回给APP进行票据的兑换，整个过程是没有问题的，但接着看该Filter，如果在请求参数中有ticket的时候也会同样结束该Filter，意思就是说在访问APP时如果参数中有ticket，那么则直接到达票据验证Filter，在验证票据的Filter中是通过底层进行的，那么仔细想下就会发现这个流程可以省去了两个重定向的过程，那么在性能方面要有多大的提升。最典型的案例就是用户个人portal，用户经过CAS认证进入portal后，通过portal访问其它业务，那么在访问之前，portal代替被访问的业务申请到了票据（PT），然后以ticket为参数传给被访问业务，那么被访问业务直接进行票据验证Filter，多么完美的一个流程。

然后说下代理模式给C/S架构的程序带来的好处：

首说CAS是不支持C/S架构程序的，因为CAS是基于票据进行认证，而票据（TGC）是存储在COOKIE中，所以C/S程序首先是不能实现CAS的认证接口，但却可以实现CAS的票据验证接口，那么如果要整合C/S程序的话，大致会有这么一个场景，用户首先通过浏览器登录到Portal并经过CAS的验证，通过Portal去访问资源已达到SSO的效果，被整合的C/S程序实现了CAS的票据验证接口，那么在访问时一般要提供账号/密码，而PT就代替了C/S程序的密码，做为一次性口令使用，以此来满足用户需求实现C/S程序的单点登录，这个也是很漂亮的一个流程

 

详细配置

最后说，CAS的代理模式并不是只服务于C/S程序的，给B/S程序带来的好处也是很刺激的。  整个CAS代理模式的配置并没有传说中的那么复杂：

环境：总共有三个工程（CAS服务系统、代理系统(cas-client-proxy)、普通业务系统（cas-client)

cas-client-proxy和cas-client都要实现CAS客户端，cas-client-proxy的web.xml配置为

 增加认证Filter:

       CAS Authentication Filter
       class>org.jasig.cas.client.authentication.AuthenticationFilterclass>

         casServerLoginUrl
         http://localhost:8080/cas/login


         serverName
         http://localhost:8080

 

增加验证票据Filter:

   CAS Validation Filter
   org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
  
     casServerUrlPrefix
     http://localhost:8080/cas
  
  
    serverName
    http://localhost:8080
  
   
        proxyReceptorUrl
        /proxyCallback
  
  
      proxyCallbackUrl
      http://localhost:8080/cas-client-proxy/proxyCallback
  
 

 

 增加两个扩展Filter:

         CAS HttpServletRequest Wrapper Filter
         class>org.jasig.cas.client.util.HttpServletRequestWrapperFilterclass>



       CAS Assertion Thread Local Filter
       class>org.jasig.cas.client.util.AssertionThreadLocalFilterclass>

 在验证票据Filter中标红的两个参数是决定此APP是否被代理模式的关键

proxyCallbackUrl参数表示接收PGT票据的地址，此地址为绝对路径

proxyReceptorUrl：经过跟踪代码，如果该参数非空，则取出该参数值所表示的绝对URL，也就是proxyCallbackUrl值。

 

配置完以上信息后，在filter-mapping中要记得为“proxyCallbackUrl”加一个url映射,如：

CAS Validation Filter

/proxyCallback

表示当访问后缀为proxyCallback的url时进入票据验证Filter

需要注意的是，如果你的应用集成了单点注销功能，则单点注销filter-mapping应该放在最前面，其次才是这个。

整个配置就完事了

 

获取PT

 

关键代码：

 Assertion assertion = (Assertion) session.getAttribute(CONST_CAS_ASSERTION));
 String pt = assertion.getPrincipal().getProxyTicketFor(service);

 参数service为被代理的业务系统地址，需要注意一点，service参数最后要有一个“/”，因为在跟踪CAS客户端代理后发现，当业务系统去验证票据时，所传的service参数后面都有一个反斜杠。

 

普通业务系统的配置基本类似，只不过在验证票据Filter中不太一样，如果普通业务系统不需要再次做为代理模式运行的话，则可以去掉proxyCallbackUrl和proxyReceptorUrl参数，然后加入

         acceptAnyProxy
         true

 

表示为通过代理票据进行验证。

 

OK，整个配置就完成了，现在可以做个实验，假如普通业务地址为“http://localhost:8080/cas-client/”，先进行portal系统，然后通过assertion对象申请到PT票据，然后打开新的浏览器，输入cas-client的地址，后面追加参数“ticket=PT-xxxxx-cas”，正常情况下是可以直接进入系统的，并且会感觉到浏览器并没有重定向的动作。

 

注：为了测试方面，我使用http协议，那么要使用http的话，需要修改CAS服务系统的两个地方

1：修改ticketGrantingTicketCookieGenerator.xml文件，将cookieSecure改为false

2：修改deployerConfigContext.xml文件，在authenticationHandlers属性中，

     p:httpClient-ref="httpClient"
     p:requireSecure="false" />

 增加标红的属性。