CAS配置学习+CAS整合Spring Securtiy配置学习（一）

考完期末试后，就开始做一个手机音频项目。该项目分为几个版本：web、 wap、client。我主要负责web版本的。在web版本的需求文档里要求使用CAS单点登录，所以我就花了三四天去研究并使用这个东西。三四天，我 自己觉得时间花的不算多，毕竟在此之前我对单点登录了解甚少，自己的水平也还不够高。

 

为了让还没了解过单点登录的人，能够容易读懂这篇文章，在这里简单介绍一下单点登录是什么。单点登录 （Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。（来源于 百度百科的解释） 笼统、简单的说，就是有几个相互信任的应用系统，分别为A、B、C、D……，只要登录其中任意一个，就可以随意访问另外的几个而无需再登录。

 

而CAS就是实现单点登录的一个开源项目，其中包括CAS Server和CAS Client。CAS Server（CAS服务器）是需要独立部署的web应用，主要负责对用户的认证工作。CAS Client（CAS客户端）支持很多开发语言，包括Java、.net、PHP、Ruby等，这里所谓的CAS客户端是指单点登录系统中的各个web应 用，负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CAS Server。

下图为CAS最基本的工作过程（图片及说明摘自网上）：

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求， CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket ，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 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 （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。