一、cas简介
全名：Central Authentication Service
特点：
1、开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、安全策略：使用票据（ Ticket ）来实现支持的认证协议；
4、支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；
5、高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等
6、支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。
二、原理
2.1 CAS Server
完成认证工作，对用户名、密码进行校验，需要独立部署，如集团SSO中的sso项目。
2.2 CAS Client
使用Filter将请求拦截下来，当请求中含票据时，重定向到CAS Server进行验证，不含票据时，到CAS Server登录页面进行登录，如集团中的esmp项目。
2.3 协议图
从结构上看，CAS包含两个部分：CAS Server 和CAS Client需要独立部署，主要负责对用户的认证工作；CAS Client负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CAS Server.图1是CAS最基本的协议过程：
CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个Web请求，同时， CAS Client会分析HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的，于是，CAS Client会重定向用户请求到CAS Server（ Step 2 ）。 Step3是用户认证过程，如果用户提供了正确的Credentials， CAS Server 会产生一个随机的 Service Ticket，然后，缓存该 Ticket ，并且重定向用户到CAS Client（附带刚才产生的Service Ticket）， Service Ticket 是不可以伪造的，最后， Step 5 和 Step6是 CAS Client 和 CAS Server之间完成了一个对用户的身份核实，用Ticket查到 Username ，因为 Ticket是 CAS Server产生的，因此，所以 CAS Server 的判断是毋庸置疑的。
该协议完成了一个很简单的任务，所有与CAS的交互均采用SSL协议，确保ST和TGC的安全性。协议工作过程会有2此重定向过程，但是CAS Client与CAS Server之间进行ticket验证的过程对于用户是透明的。
1. 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
2. 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
3. 用户认证：用户身份认证。
4. 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。
5. 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
6. 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。
2.4 时序图
比如A、B两个CAS客户端，当A登录后，A中保存session（流程这里不做重述，见上图），那这个时候B再去请求，应该是不用再次输入用户名密码认证的。具体流程：
浏览器拿着cookie到B（上图1）；B发现没有session，会到CAS服务端去认证，发现是已登录用户，所以返回ST重定向到浏览器（上图2）；浏览器再重定向到B并发送ST参数（上图4）；B再去CAS Server认证ST，确认已登录（上图5）；创建session （上图6）；登录成功（上图7）