CAS原理与协议
SSO是在多个应用系统中，用户仅仅须要登录一次就能够訪问全部相互信任的应用系统。
SSO的解决方式非常多，比方收费的有UTrust、惠普灵动等，开源的有CAS、Smart SSO等，当中应用最为广泛的是CAS。
CAS （Central Authentication Service）中央认证服务。CAS(Central Authentication Service)是一款不错的针对 Web 应用的单点登录框架。
CAS 具有下面特点：
开源的企业级单点登录解决方式。
CAS Server 为须要独立部署的 Web 应用。
CAS Client 支持许多的client(这里指单点登录系统中的各个 Web 应用)。包含 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
CAS 原理和协议
结构上： CAS 包括两部分
1、CAS Server
CAS Server 负责完毕对用户的认证工作， CAS Server 须要独立部署，有不止一种 CAS Server 的实现。
CAS Server 会处理username / password等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件里检索用户password，对这样的方式。 CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 到底是用何种认证方式。跟 CAS 协议是分离的，也就是。这个认证的实现细节能够自己定制和扩展。
2、CAS Client
CAS Client 负责部署在client（指 Web 应用）。原则上， CAS Client 的部署意味着。当有对本地 Web 应用的受保护资源的訪问请求。而且须要对请求方进行身份认证， Web 应用不再接受不论什么的usernamepassword等类似的 Credentials ，而是重定向到 CAS Server 进行认证。
眼下， CAS Client 支持（某些在完好中）许多的client，包含 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等client，差点儿可以这样说， CAS 协议可以适合不论什么语言编写的client应用。
协议：
整个协议的基础思想都是基于票据方式。
以下，我们看看CAS的基本协议框架：
CAS Client 与受保护的client应用部署在一起，以 Filter 方式保护受保护的资源。对于訪问受保护资源的每一个 Web 请求。CAS Client 会分析该请求的 Http 请求中是否包括 Service Ticket。假设没有。则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址。并传递 Service （也就是要訪问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，假设登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证。之后系统自己主动重定向到 Service 所在地址，并为client浏览器设置一个 Ticket Granted Cookie（TGC）。CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适。以确保 Service Ticket 的合法性。
在该协议中。全部与 CAS 的交互均採用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，可是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
另外。CAS 协议中还提供了 Proxy （代理）模式。以适应更加高级、复杂的应用场景
