统一身份认证（CAS）简单说明与设计方案（转）
1. 单点登录概述
所谓单点登录（SSO），只当企业用户同时访问多个不同（类型的）应用时，他们只需要提供自身的用户凭证信息（比如用户名/密码）一次，仅仅一次。SSO解决方案（比如，CAS）负责统一认证用户，如果需要，SSO也可以完成用户的授权处理。可以看出，当企业用户在不同的应用间切换时，他们不用再重复地输入自身的用户凭证了。在实施SSO后，所用的认证操作都将交给SSO认证中心。现有的SSO解决方案非常多，比如微软的MSN Passport便是典型的SSO解决方案，各Java EE容器都提供了自身的专有SSO能力。
2. CAS的总体架构
1. CAS简介
CAS（中央认证服务）是建立在非常开放的协议之上的企业级SSO解决方案。诞生于2001年，在2002年发布了CAS2.0协议，这一新的协议提供了Proxy（代理）能力，此时的CAS2.0支持多层SSO能力。到2005年，CAS成为了JA-SIG旗下的重要子项目。由于CAS2.0版本的可扩展能力不是非常完美，而且他的架构设计也不是很卓越，为了使得CAS能够适用于更多场合，JA-SIG打算开发出同时遵循CAS1.0和CAS2.0协议的CAS3.X版本。
现在的CAS3全面拥抱Spring技术，比如Spring DI容器和AOP技术、Spring Web MVC、Spring Web Flow、Spring Ldap Template等。
通常，CAS3由两部分内容构成：CAS3服务器和CAS客户端。由于CAS2.0协议借助于XML数据结构与客户进行交互，因此开发者可以使用各种语言编写的CAS3客户与服务器进行通信。CAS3服务器采用纯Java开发而成，它要求目标运行环境实现了Servlet2.4+规范、提供Java SE 1.4+支持。如果宿主CAS3服务器的目标Java EE容器仅仅实现了Servlet2.3-规范，则在对CAS3服务器进行少量的改造后，CAS3也能运行其中。
运行时，CAS3服务器仅仅是一个简单的Web应用，使用者只需要将cas.war直接丢到目标Java EE容器后，即完成了CAS3的部署。
2. CAS词汇概念
TGC(ticket-granting cookie)--------- 受权的票据证明 KDC( Key Distribution Center ) ---------- 密钥发放中心
Service ticket(ST) --------- 服务票据， 由 KDC 的 TGS 发放。 任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 (Applications) 。 如果能正确接收 Service Ticket ，说明在 CASClient-CASServer 之间的信任关系已经被正确建立起来，通常为一张数字加密的证书 Ticket Granting tieckt(TGT) --------- 票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交身份认证信息 ( 准确术语是 Credentials) 。
authentication service (AS) --------- 认证用服务，索取 Crendential ，发放 TGT ticket-granting service (TGS) --------- 票据授权服务，索取 TGT ，发放 ST
3. CAS工作原理
CAS的单点登录的认证过程，所用应用服务器受到应用请求后，检查ST和TGT，如果没有或不对，转到CAS认证服务器登录页面，通过安全认证后得到ST和TGT，再重新定向到相关应用服务器，在回话生命周期之内如果再定向到别的应用，将出示ST和TGT进行认证，注意，取得TGT的过程是通过SSL安全协议的。
如果通俗形象地说就是：相当于用户要去游乐场，首先要在门口检查用户的身份 ( 即 CHECK 用户的 ID 和 PASS), 如果用户通过验证，游乐场的门卫 (AS) 即提供给用户一张门卡 (TGT)。
这张卡片的用处就是告诉游乐场的各个场所，用户是通过正门进来，而不是后门偷爬进来的，并且也是获取进入场所一把钥匙。
现在用户有张卡，但是这对用户来不重要，因为用户来游乐场不是为了拿这张卡的而是为了游览游乐项目，这时用户摩天楼，并想游玩。
这时摩天轮的服务员 (client) 拦下用户，向用户要求摩天轮的 (ST) 票据，用户说用户只有一个门卡 (TGT), 那用户只要把 TGT 放在一旁的票据授权机 (TGS) 上刷一下。
票据授权机 (TGS) 就根据用户现在所在的摩天轮，给用户一张摩天轮的票据 (ST), 这样用户有了摩天轮的票据，现在用户可以畅通无阻的进入摩天轮里游玩了。
当然如果用户玩完摩天轮后，想去游乐园的咖啡厅休息下，那用户一样只要带着那张门卡 (TGT). 到相应的咖啡厅的票据授权机 (TGS) 刷一下，得到咖啡厅的票据 (ST) 就可以进入咖啡厅
当用户离开游乐场后，想用这张 TGT 去刷打的回家的费用，对不起，用户的 TGT 已经过期了，在用户离开游乐场那刻开始，用户的 TGT 就已经销毁了 。
3. CAS的实现原理
由于CAS是基于Cookie的服务，所以它使用了Spring CookieGenerator来生成相应Cookie，下面的代码段摘自与CAS服务器的WEB-INF/中的cas-server.xml配置文件。
class=\ork.web.util.CookieGenerator\
一旦用户登录到CAS服务器后，可以借助于URL为/cas/logout的地址退出，并且这种logout结果将导致浏览器中已存储的Cookie被销毁掉，即销毁CAS与当前用户间已建立的信任关系（Web SSO会话）。
1. AuthenticationHandler认证处理器
浏览项目的web.xml，可以发现如下内容：
contextConfigLocation
/WEB-INF/applicationContext.xml,
/WEB-INF/deployerConfigContext-acegi.xml
org.jasig.cas.web.init.SafeContextLoaderListener
SafeContextLoaderListener实现了SafeContextListener，它借助于ContextLoader -Listener装载Spring DI容器。这样做的原因是因为Spring在通过
ContextLoaderLitener启动时可能出现异常，造成整个CAS不能正常启动，经过SafeContextLoaderListener，则在异常发生时，CAS服务器也可以启动。
在deployerConfigContext.xml中，可以看到只定义了一个Bean：
class=\
SimpleTestUsernamePasswordAuthenticationHandler的作用是如果用户名与密码输入一样，则通过系统认证。这个是开发过程中常用的一个handler，但是在开发完毕后应该除去。
AuthenticationManagerImpl负责认证用户，比如一个admin/admin用户是否合法就是它来验证的。AuthenticationManagerImpl对象会借助于他引用的credentialsToPr -incipalResolvers和authenticationHandlers集合完成用户的认证工作。Authentication -Handlers负责完成用户认证，而
credentialsToPrincipalResolvers负责构建认证结果。其中，并不是authenticationHandlers的全部集合都参与到用户认证中，一旦某个AuthenticationHandler成功完成用户的认证，则认证进程就到此为止，进而转到credenti -alsToPrincipalResolvers来构建认证结果。credentialsToPrincipalResolvers的过程也类似于此。
2. CAS的时序图
