近期做单点登录，看了一些CAS资料，做下总结
一、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 协议图
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）