snoopy

http://www.coin163.com/java/docs/201305/d_2795028902.html

cas 是什么？JA－SIG 中央认证服务(Central Authentication Service简称CAS)是一个开源的企业级单点登录的java 服务器组件。客户端有多种语言实现，包括:PHP,PL/SQL,java，.NET等.它的官方网站http://www.jasig.org/cas.CAS项目于2001年在Yale大学习兴起，起初由Shawn Bayen开发。最初cas

从cas 3.2版本开始，cas支持spring的配置，所有关于spring的配置信息只需放入WEB-INF/spring-configuration目录即可，cas启动时会自动加载。这个目录下的spring配置文件几乎不需要改动。（下面所列的文件是3.5.2版本的）1./WEB-INF/spring-configuration/applicationContext.xml这个配置文件是c

cas client有多种语言实现，cas client主要分为以下几种：1.官方客户端主要实现有java client，.net client，php client等2.遗留的客户端主要是cas client2.0版本，另外还有pl/sql client,python client，pam_cas client,asp client,perl client等3.正在开发的

cas 分为服务端，与客户端，那么客伊妹儿

在cas 2.0协议中，cas 终于支持单点登出（d）

之前我分析过cas的spring配置文件，其中有一个spring文件名为：

一qk

假设cas server服务地址：http://cas-server:8080/cascas client集成的应用地址：http://cas-client:8070/castestcas client端：1.用户在浏览器访问http://cas-client:8070/castest/index.jsp2.在castest应用判断用户没有登录，就重定向到cas serve

jdbc认证配置示例打开cas/WEB-INF/deployerConfigContext.xml,在底部应当能够找到这个是cas 提供的默认认证处理器，只要用户名等于密码就可以通过认证。可以用一个或多个jdbc认证方式去替换这个认证方式.      class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAut

cas 作为单点登录的解决方案，提供了多种方式的认证方案，至于用哪一种或哪几种，这个取决于用户，cas并没有什么要求。对于用户来说，开箱即用，将你希望的认证方式配到认证处理器链表中就可以。cas 主要提供了以下几种认证方案：jaas,generic,jdbc,ldap,legacy,radius,spnego,trusted,x509,oauth,openid.而有些认证对于web开发，基

GENERIC(普通认证)需要增加cas-server-support-generic-3.5.2.jar普通认证很简单，就是将你需要认证的用户名、密码对存放在cas 服务端，一种式是直接配置在spring的配置中，另外一种是配置在文件文件即文件系统的认证处理器，accept user authentication handlerfile s

1.JAAShttp://www.blogjava.net/fastunit/archive/2008/01/28/178204.htmlJAAS(java authentication authorization service即java验证和授权api)，虽然都说它具有灵活性什么的。它的配置很简单，并且也不需要增加额外的jar包。但是它对我来说不太好用，因为

jdbc认证处理器需要增加cas-server-support-jdbc-3.5.2.jar对于jdbc认证处理器，包含三个3.1.org.jasig.cas.adaptors.jdbc.BindModeSearchDatabaseAuthenticationHandler根据提供的用户名及密码，认证是否能够连上相应的数据库，如何可以则认证成功，反之则认证失败,它需要一个参数dat

关于cas的ldap认证，可以参看http://blog.163.com/magicc_love/blog/static/18585366220132294648822/这篇文章对于如何配置ldap已介绍的算是比较全面了.后面我主要描述一下这两个的认证逻辑.org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler 认

cas认证过程中涉及两类ticket，一类是TGT,一类是ST,在默认的情况下，这些ticket是存储在服务端的内存的。为了更好的提高服务器的性能，以及cas服务器集群化，cas系统又提供了几种ticket的存储方案。cas一共提供了如下几种存储方案：ConcurrentHashMap ticket存储,这个也是默认存储方案；jpa ticket存储;ehcache ticke

cas 默认ticket存储放在ConcurrentHashMap，因为这种存储方式对于单个cas server服务器，那是再合适不过了，当然对于它的性能调整，也就是对于ConcurrentHashMap的性能调整，默认情况下配置是：moreTicketRegistry涉及到三个参数：initialCapacity - 初始容量。该实现执行内部大小调整，以容纳这些元素。lo

jpa ticket存储，也就是可以让cas将ticket存储在后端的数据库，比如oracle,mysql等。这个功能可以让我们来构建高可用的cas 服务器集群。下面我会描述具体的配置,让cas如何将ticket存入后端oracle数据库，我在实际生产应用中也是存入oracle数据库的，因为公司只有oracle数据库。其实存在哪个数据库都一样，相互转换很容易，只需要更改一下数据源及数据库驱

class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">class="org.jasig.cas.ticket.registry.EhCacheTicketRegistry"p:serviceTicketsCache-ref="serviceTicketsCache"p:ticketGr

class="org.jasig.cas.ticket.registry.MemCacheTicketRegistry">

cas 的审记日志记录用到了Inspektr.Inspektr是什么呢？带着这个问题，查找了它的官网https://code.google.com/p/inspektr/现在源代码移到了https://github.com/dima767/inspektr,代码结构并且进行了重构。简而言之Inspektr就是一个很小的无侵入的代码审记jar包。它对于spring所托管的bean可以从如

Inspektr在cas中配置如下(在cas/WEB-INF/spring-configuration/auditTrailContext.xml这个文件中,参看cas入门之二spring配置文件): xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org

用户错误登录限制简而言之就是限制单个用户单位时间内登录系统的错误次数。当用户在单位时间内登录系统的次数达到上限，就对这个用户采取相应的措施。对于单节点CAS情况下，用户登录限制有两个方法：一是按IP地址限制，另一个通过IP地址+用户名组合限制。 对于多节点CAS情况下，只能结合Inspektr的审计功能来限制用户登录。首先配置了限制用户登录的拦截器。当一个用户在单位

cas 提供了可插拔式的ticket过期策略框架用于tgt和st。在cas应用中，tgt和st的过期策略配置默认在cas/webapp/WEB-INF/spring-configuration/ticketExpirationPolicies.xml文件中。在cas的过期策略中，并没有明确指出哪一种ticket应用于哪一种过期策略，但是我们根据类名，还是能够进行区分的。但是并不能说明这个过期策

当用户成功认证之后，cas服务器向客户端返回尽量多的用户信息回去，默认是只返回用户名，当需要返回更多的信息时，就需要用到person directory。在用户认证成功之后，cas服务器有一步是将credentials向Principal转化的过程，这个工作是由credentialsToPrincipalResolvers完成，参见　认证管理器。cas 应用的默认配配置是：

在很多情况下，需要从多个数据源中获取用户信息，然后合并相关的信息返回给客户端。在person directory中有两种方式来解决这个问题，一是MergingPersonAttributeDaoImpl， 即将多个IPersonAttributesAttributeDao获取到的用户信息，进行合并成一个结果集，默认是将几个结果集相同属性的合成在一起，然后返回给客户端；另一个是Cas

cas 默认是以https 协议发布的，我一直对这个问题避而不谈，因为这个涉及到ssl协议，不是那么容易搞的。我在公司应用cas也是以http协议发布的，因为这个集成公司内网应用，没有必要弄一个证书，花钱出力不讨好。但是即然提到这个https，那么从学习的角度来看，我们也应当学习一下。下面以oracle jdk 1.7为例应用keytool自己制作一个https证书（下面以单认证的方式

当ticket存储器，没有能力管理ticket的状态时，则需要ticket清理器。默认的内存ticket存储器，jpa存储器等都需要ticket清理器;memecached ,ehcache等存储器则不需要ticket清理器。默认情况下，ticket 清理器配置在cas/WEB-INF/spring-configuration/ticketRegistry.xml文件中，如下所示：

什么是cas services管理控制台?想想一种情况，当你搭建好了一台cas服务器，大家知道了cas的访问地址，那么你能否有能力控制住哪些应用才能够经过你搭建的cas服务器进行认证吗？你可能会说，大家不会乱连，进行认证的。再想想一种情况，如果经过后台监控，发现有一个应用链接经过你的cas应用进行认证，一下就让你的cas服务器cpu 100%,那么你如何去控制这个链接呢？现在我很高

cas支持单点登出了，那么它的基本机制是什么呢？当用户经cas认证成功之后，就可以访问集成于cas的所有应用，而无需登录。那么认证是基于cookie的，因为cas在cookie是放了tgt，这样用户就可以无须二次登录，就可以访问另外的应用。但是cas为了安全，会给tgt设置一个过期的期限。当tgt过期之后，则cas会轮训这个tgt所访问的cas client端应用，并向每个cas

cas登录之后，产生tgt，当tgt过期之后，cas会自动消毁服务器端的tgt存根。如果开启自动登出（cas默认是开启的），则cas会向应用端发送自动登出请求，应用接到这个请求，会消毁相应的session,这样就完成了自动登出。之后用户，再次访问应用，就会出现页面假死，此时用户会刷新页面，则会出现登录页面。用户输入用户名/密码直接登录就可以了。但是实际应用时出现了很大的问题，那就是

项目所应用的cas 3.5.2，运行环境为tomcat7.0.52.因项目需要，所以将cas　ticket经jpa持久化到oracle　11g 数据库。根据这个cas 3.5.2的pom.xml文件，所应用的hibernate jar罗列如下：hibernate-commons-annotations-4.0.1.Final.jarhibernate-core-4.1.0.Final.

cas 的运行环境是tomcat,cas的集群主要分为两部分，一是登录过程中session的集群，二是登录之后产生的ticket的集群。对于登录之后产生的ticket的集群，则相对容易，根据我前几篇文章可以找到答案，比如将ticket 以jpa的形式存到外部数据库即可以。那么对于登录过程中session的集群，对于tomcat则进行session复制。tomcat的session复制目前有

cas 的运行环境是tomcat,cas的集群主要分为两部分，一是登录过程中session的集群，二是登录之后产生的ticket的集群。对于登录之后产生的ticket的集群，则相对容易，根据我前几篇文章可以找到答案，这两部分可以通过组合完成，达成相应的目的。对于cas ticket集群，目前测试通过的有三种方式1.jpa ticket repositry 参看2.echcache