JA-SIG（CAS）的设计愿景：
简单的说，CAS（Central Authentication Service – 中心认证服务）的目的就是使分布在一个企业内部各个不同异构系统的认证工作集中在一起，通过一个公用的认证系统统一管理和验证用户的身份。在CAS上认证的用户将获得CAS颁发的一个证书，使用这个证书，用户可以在承认CAS证书的各个系统上自由穿梭访问，不需要再次的登录认证。打个比方：对于加入欧盟的国家而言，在他们国家中的公民可以凭借着自己的身份证，在整个欧洲旅行，不用签证。对于企业内部系统而言，CAS就是这个颁发欧盟认证的系统，其它系统都是加入欧盟的国家，它们要共同遵守和承认CAS的认证规则。
因此CAS的设计愿景就是：
1。实现一个易用的、能跨不同Web应用的单点登录认证中心；
2。实现统一的用户身份和密钥管理，减少多套密码系统造成的管理成本和安全漏洞；
3。降低认证模块在IT系统设计中的耦合度，提供更好的SOA设计和更弹性的安全策略

CAS1.0服务架构实现：
传统的用户认证流程
我们以A公司的员工日志管理系统为例，如下图：


使用CAS后的用户认证流程


示意图中，CAS相关部分被标示为蓝色。在这个流程中，员工AT向日志系统请求进入主页面，他的浏览器发出的HTTP请求被嵌入在日志系统中的CAS客户端（HTTP过滤器）拦截，并判断该请求是否带有CAS的证书；如果没有，员工AT将被定位到CAS的统一用户登录界面进行登录认证，成功后，CAS将自动引导AT返回日志系统的主页面。


CAS的程序逻辑实现
要完成上述的认证业务，CAS需要一个认证中心服务器CAS -Server和嵌入在不同业务系统方的认证客户端CAS-Client的协同。

在CAS1.0协议中，CAS-Server提供的三个验证服务接口（web服务URL）：
1. 用户登录URL，形如 https://casserver/cas/servlet/login
2. 用户凭证校验URL，形如 https://casserver/cas/servlet/validate
3. 用户登出URL，形如 https://casserver/cas/servlet/logout

在CAS-Client端，CAS提供了多样化的语言支持，其中用于java的是一个casclient.jar包。目前的版本为2.1.1，其中提供了三种形式的凭证校验：
1. 用于Java Servlets的Filter — edu.yale.its.tp.cas.client.filter.CASFilter
2. 用于JSP页面的CAS Tag Library
3. 通用Java API Object — ServiceTicketValidator / ProxyTicketValidator

通常，企业应用程序基于浏览器的B/S模式，这种情况下，系统的用户凭证（一个由CAS服务器生成的唯一 id号，也称之为ticket）借助cookie和URL参数方式实现；在B/S环境中，大多情况下，我们只需要配置CAS Filter或者使用CAS Tag Library就可以轻松实现的验证客户端。
如果应用是以普通的C/S模式运行，则需要应用程序自己来维护这个ticket在上下文环境中的传输和保存了。这时候就需要手工调用ServiceTicketValidator / ProxyTicketValidator对象的方法，向CAS 服务器提交认证，并获取认证结果进行相应的处理。


CAS服务的具体实现
环境假设：用户User要访问业务系统Biz；Biz系统部署在bizserver上；CAS的系统搭建在服务器casserver上。

图例说明：
Step1: 用户第一次访问Biz系统主页http://bizserver/index.jsp ;部署在Biz系统上的CASFilter发现用户尚未登录，将用户重定向的CAS登录界面 https://casserver/cas/servlet/login?service=http://bizserver/index.jsp ，同时在重定向的URL上用service参数将用户的目标地址传给CAS服务器。

Step2:用户在CAS的登录页上输入用户名密码登录，CAS服务器认证通过后，生成一个ticket，并带在目标地址的尾部返回客户端的浏览器redirect：http://bizserver/index.jsp?ticket=casticket.

Step3:客户端浏览器获得CAS服务器的认证应答，取得凭证ticket后，使用重定向的链接http://bizserver/index.jsp?ticket=casticket访问Biz服务

Step4: BizServer上的CASFilter再次过滤访问请求，并获得ticket凭证。Filter将使用该凭证通过URL https://casserver/cas/servlet/validate?service= http://bizserver/index.jsp &ticket=casticket 向CAS认证中心确认对应的服务请求和凭证是否有效。根据CAS服务器返回的结果，如果凭证有效，则CASFilter允许用户进入http://bizserver/index.jsp 所指向的页面；否则，再次重定向到https://casserver/cas/servlet/login?service=http://bizserver/index.jsp 上要求用户进行认证。


CAS2.0服务架构实现：
CAS2.0的协议主要是针对web应用的SSO功能增强的协议，它在1.0协议基础上扩展了Proxy Authentication（代理认证）能力。那么什么是Proxy Authentication呢？！

代理认证Proxy Authentication
假设有一下这样的应用场景：用户AT早晨来到公司，他的第一件事就是进入公司的Portal系统浏览一天的新咨询，如股票信息、天气情况、业界新闻。他通过CAS的身份认证登录了门户系统，看到了他订制的信息。之后，他要访问portal中的邮件信息，看看有没有新的邮件。这时候Portal系统必须访问他的IMAP服务器，这需要他的私人密码。我们知道Portal是通过CAS对AT进行认证的，因此Portal上没有AT的个人密码信息。这时，我们发现，Portal需要代表AT的身份向IMAP服务器提交身份认证，而这正是Proxy Authentication的作用。

CAS2.0系统架构中的角色


CAS2.0系统中的用到的凭证（ticket）


以上对于CAS2.0协议中用到的5种ticket的说明，乍看起来也许会让你云里雾里的。没关系，下面我们就来详细阐述这5种凭证在实际认证流程中的作用。在阐述具体流程前，我们要先关注一下2.0协议中对客户端配置的需求.

CAS2.0的客户端配置
在2.0协议中，CAS-Server端的配置与1.0基本一致。但在客户端上，多增加了一个call back URL，该URL用来提供server端向client端传输PGT时使用。因此，除了要配置edu.yale.its.tp.cas.client.filter.CASFilter作为认证过滤器外，还要配置edu.yale.its.tp.cas.proxy.ProxyTicketReceptor这个servlet，作为server回传PGT的call back URL，如下：


CAS2.0代理认证流程
以下的流程图模拟上述的用户AT通过Portal向他的IMAP邮件服务器请求电子邮件的认证过程。在该过程中，充当Service和Proxy两个角色的Portal使用CAS Filter对访问其自身的用户进行CAS认证；同时Portal要使用ProxyTicketReceptor servlet接收来自CAS server的PGT信息，并使用ProxyTicketValidator对象向CAS获取访问IMAP服务器的Proxy Ticket凭证；最终从IMAP服务器上获取AT用户的mail信息。同样的，这里的IMAP服务器也要接受并认可CAS对其用户的认证管理，同时它自己也成为二级Proxy，在有需要的情况下，一样可以向它的back-end Service发起Proxy Authentication代理认证请求……

其中蓝色线表示HTTP或HTTPS的请求；红色线表示应答；黑色线表示来自CAS server端的回调操作。

到此，本章节对JA-SIG（CAS）的整体功能和身份认证业务架构进行初步的讲解，在后续的章节中，我们将对CAS平台的服务端和客户端的编程与应用定制等相关内容的进行介绍。