CAS单点登录系统原理及解决方案
SSO原理
SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就
可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一
个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
当我们提起SSO的时候，我们通常是指Web SSO，它的主要特点是，SSO应用之间走Web协
议(如 HTTP/SSL)，并且SSO都只有一个登录入口。
简单的SSO的体系中，会有下面三种角色：
1，User（多个）
2，Web应用（多个）
3，SSO认证中心（ 1 个）
虽然SSO实现模式千奇百怪，但万变不离其宗：
Web应用不处理User的登录，否则就是多点登陆了，所有的登录都在SSO认证中心进行。
SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三/李四。
SSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判
断会通过某种方法告之Web应用，而且判断结果必须被Web应用信任。
一、 CAS 中央认证服务
CAS
即：
Central Authentication Service
，中央认证服务。
1.1 CAS 的结构体系
从结构体系看，CAS包含两部分： CAS Server 和 CAS Client
1.1.1 CAS Server
CAS Server 负责完成对用户的认证工作，CAS Server需要独立部署，有不止一种CAS
Server的实现，Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名/密码等凭证 (Credentials)，它可能会到数据库检索一条用户帐号
信息，也可能在XML文件中检索用户密码，对这种方式，CAS 均提供一种灵活但同一的接口/
实现分离的方式，CAS 究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实
现细节可以自己定制和扩展。
1.1.2 CAS Client
CAS Client 负责部署在客户端（注意，我是指Web应用），原则上，CAS Client 的部署意味
着，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web
应用不再接受任何的用户名密码等类似的Credentials，而是重定向到CAS Server进行认证。
目前，CAS Client支持（某些在完善中）非常多的客户端，包括Java 、.Net 、ISAPI 、Php 、
Perl 、uPortal 、Acegi 、Ruby 、VBScript 等客户端，几乎可以这样说，CAS 协议能够适
合任何语言编写的客户端应用。
1.2 CAS 协议
CAS 的代理模式要相对复杂一些，它引入了一些新的概念，CAS 协议应该是由 Drew Mazurek
负责可开发的，从 CAS v1 到现在的 CAS v3 ，整个协议的基础思想都是基于 Kerberos 的
票据方式。
CAS v1 非常原始，传送一个用户名是
”
yes\ndavid.turing
”
的方式， CAS v2 开始使
用了 XML 规范，大大增强了可扩展性， CAS v3 开始使用 AOP 技术，让 Spring 爱好者
可以轻松配置 CAS Server 到现有的应用环境中。
CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket) ，通过 ST 来访问服
务，而 CAS 也有对应 TGT ， ST 的实体，而且他们在保护 TGT 的方法上虽然有所区别，
但是，最终都可以实现这样一个目的
——
免去多次登录的麻烦。
下面，是 CAS 的基本协议框架：
1.2.1 基础协议
CAS 基础模式
上图是一个最基础的 CAS 协议，CAS Client 以Filter方式保护Web应用的受保护资源，
过滤从客户端过来的每一个Web请求，同时，CAS Client会分析HTTP请求中是否包请求
Service Ticket( 上图中的 Ticket)，如果没有，则说明该用户是没有经过认证的，于是，CAS
Client会重定向用户请求到 CAS Server （ Step 2 ）。Step 3 是用户认证过程，如果用户提
供了正确的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 的判断
是毋庸置疑的。
该协议完成了一个很简单的任务，就是 User(david.turing) 打开IE，直接访问 helloservice
应用，它被立即重定向到CAS Server进行认证， User可能感觉到浏览器在 helloservcie 和
casserver 之间重定向，但User是看不到，CAS Client和CAS Server 相互间的Service Ticket
核实 (Validation) 过程。当CAS Server告知CAS Client用户， Service Ticket 对应确凿身份
，CAS Client 才会对当前Request 的用户进行服务。
1.2.2 CAS 如何实现 SSO
当我们的Web时代还处于初级阶段的时候，SSO是通过共享cookies来实现，比如下面三
个域名要做 SSO ：
http://www.blogjava.net/
http://www.matrix.org.cn/
http://www.csdn.net/
如果通过 CAS 来集成这三个应用，那么，这三个域名都要做一些域名映射，
http://blogjava.cas.org/
http://matrix.cas.org/
http://csdn.cas.org/
因为是同一个域，所以每个站点都能够共享基于 cas.org 的 cookies 。这种方法原始，不灵
活而且有不少安全隐患，已经被抛弃了。
CAS 可以很简单的实现跨域的 SSO ，因为，单点被控制在 CAS Server ，用户最有价值的
TGC-Cookie 只是跟 CAS Server 相关， CAS Server 就只有一个，因此，解决了 cookies
不能跨域的问题。
回到 CAS 的基础协议图，当 Step3 完成之后， CAS Server 会向 User 发送一个 Ticket
granting cookie (TGC) 给 User 的浏览器，这个 Cookie 就类似 Kerberos 的 TGT ，下次
当用户被 Helloservice2 重定向到 CAS Server 的时候， CAS Server 会主动 Get 到这个 TGC
cookie，然后做下面的事情：
1，如果User的持有 TGC且其还没失效，那么就走基础协议图的 Step4，达到了SSO的效果。
2，如果TGC失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
1.2.3 CAS 的代理模式
模式 1 已经能够满足大部分简单的SSO 应用，现在，我们探讨一种更复杂的情况，即用
户访问 helloservice ， helloservice 又依赖于 helloservice2 来获取一些信息，如同：
User
�
helloservice
��
helloservice2
这种情况下，假设 helloservice2 也是需要对 User 进行身份验证才能访问，那么，为了不影
响用户体验（过多的重定向导致 User 的 IE 窗口不停地 闪动 )，CAS 引入了一种 Proxy 认
证机制，即CAS Client 可以代理用户去访问其它Web应用。
代理的前提是需要CAS Client拥有用户的身份信息 ( 类似凭据 ) 。与其说之前我们提到的 TGC
