1. CAS配置文件1.1. What is CAS？
cas (centralauthenticationservice )是由Yale大学发起的一个企业级开源项目，是一个可信赖的单点登录解决方案(Web SSO )
CAS始于2001年，2004年12月正式成为JA-SIG项目。
1.2 .主要特性
1、开源、多协议SSO解决方案protocols :客户协议、CAS、OAuth、OpenID、rest风格的API、SAML1.1、SAML2.0等。
2、支持多种身份验证机制：活动目录、JAAS、JDBC、LDAP、x.509认证等；
3、安全策略：使用票据(Ticket )实现支持的认证协议；
4、支持授权：可以确定哪些服务可以请求和验证服务票据(Service Ticket )；
5、提供高可用性：通过将经过身份验证的状态数据存储在TicketRegistry组件中，这些组件支持分布式环境的实现。 例如BerkleyDB、Default、EhcacheTicketRegistry、JDBCTicketRegistry、jboss
6、支持各种客户端，包括Java、 Net、PHP、Perl、Apache和uPortal。
2. SSO单点登录原理本文内容主要针对Web SSO。
2.1 .什么是SSO
单点登录(Single Sign-On，简称SSO )是为企业业务集成提供服务的最常用的解决方案之一。 通过SSO，在多个APP应用系统中，只要**登录一次就可以访问相互信任的所有APP应用系统。
2.2. SSO原理
2.2.1 .在SSO体系中的作用
一般SSO系统的主要作用有三个。
1、用户(多个) )。
2、web APP (多个)。
3、SSO认证中心(**1个** )
2.2.2. SSO实现模式原则
SSO实现模式一般包括以下三个原则：
1、所有认证注册均在SSO认证中心进行；
2.SSO认证中心通过几种方式告知当前访问web APP应用程序的用户是否为经过认证的用户
3、SSO认证中心与所有web APP应用建立信任关系。 也就是说，web APP应用必须信任认证中心。 (单一信任() ) ) ) ) )。
2.2.3. SSO的主要实现方式
SSO的主要实施方法如下。
1、分享饼干
基于共享域的cookie是Web早期使用的一种方法，它利用浏览域并自动传递cookie的机制来实现在两个域之间传递系统令牌的问题。 另外，关于跨域问题，cookies本身并不进行跨域，但可以利用它实现跨域的SSO。 例如，代理、暴露SSO令牌值等。
坏处：不灵活，安全隐患多，被抛弃。
2、broker-based (基于kyd xy ) ) ) ) ) ) ) ) )。
该技术的特点是具有集中身份验证和用户帐户管理服务。 kydxy提供对用于进一步请求的电子身份的访问。 使用中央数据库可以降低管理成本，并为身份验证提供公共、独立的“第三方”。 例如Kerberos、Sesame、IBM KryptoKnight (凭证存储库思想)等。 Kerberos是麻省理工学院发明的安全认证服务，通过UNIX和Windows作为默认安全认证服务集成在操作系统中。
3、基于代理) ) ) ) ) )。
此解决方案具有自动验证不同APP应用的用户id的代理。 这个代理需要设计成具有不同的功能。 例如，可以使用口令表或加密密钥自动为用户消除验证负担。 代理位于服务器上，充当服务器认证系统和客户端认证方法之间的“翻译”。 例如SSH等。
4、基本
例如，SecureID、WebID、例如FTP、邮件服务器的登录认证等，是让单个密码与多个APP应用的方便方法。
5、基于网关
6、基于SAML
安全辅助标记语言(SAML )的出现大大简化了SSO，并被OASIS批准为**SSO的执行标准。 开源组织OpenSAML实现了SAML规范。
3. CAS基本原理3.1 .体系结构
从体系结构来看，CAS有两个部分： CAS
erver 和 CAS Client 。3.1.1. CAS Server
CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。
3.1.2. CAS Client
负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
3.2. CAS 原理和协议
3.2.1. 基础模式
基础模式 SSO 访问流程主要有以下步骤：
访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。用户认证：用户身份认证。发放票据： SSO 服务器会产生一个随机的 Service Ticket 。验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。下面是 CAS 最基本的协议过程：
CAS实现SSO单点登录原理
基础协议图
如 上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同 时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , **并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） **； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 **2 次重定向 **的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection ）。
CAS 请求认证时序图如下：
CAS实现SSO单点登录原理
3.2.1. CAS 如何实现 SSO
当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。3.2.2. CAS 代理模式
该模式形式为用户访问 App1 ， App1 又依赖于 App2 来获取一些信息，如： User -->App1 -->App2。
这 种情况下，假设 App2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地 闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。
代 理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据，这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借TGC ， User 可以免去输入密码以获取访问其它服务的 Service Ticket ，所以，这里凭借 PGT ， Web应用可以代理用户去实现后端的认证，而 **无需前端用户的参与 **。
下面为代理应用（ helloService ）获取 PGT 的过程： （注： PGTURL 用于表示一个 Proxy 服务，是一个回调链接； PGT 相当于代理证； PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系；）
CAS实现SSO单点登录原理
如上面的 CAS Proxy 图所示， **CAS Client **在基础协议之上，在验证 ST 时提供了一个额外的PGT URL( 而且是 SSL 的入口 ) 给 CAS Server ，使得 CAS Server 可以通过 PGT URL 提供一个 PGT 给 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通过 PGT 向后端 Web 应用进行认证。
下面是代理认证和提供服务的过程：
CAS实现SSO单点登录原理
如 上图所示， Proxy 认证与普通的认证其实差别不大， Step1 ， 2 与基础模式的 Step1,2 几乎一样，唯一不同的 是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。
3.2.3. 辅助说明
CAS 的 SSO 实现方式可简化理解为： 1 个 Cookie 和 N 个 Session 。 CAS Server 创建 cookie，在所有应用认证时使用，各应用通过创建各自的 Session 来标识用户是否已登录。
用 户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在 session 里读取到用户信息，所以就不会去 CAS Server 认证。如果在此浏览器里访问别的 web 应用时，客户端应用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server 的 login 接口认证，但这时CAS Server 会读取到浏览器传来的 cookie （ TGC ），所以 CAS Server 不会要求用户去登录页面登录，只是会根据 service 参数生成一个 Ticket ，然后再和 web 应用做一个验 证 ticket 的交互而已。
3.3. 术语解释
CAS 系统中设计了 5 中票据： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放用户身份认证凭证的 cookie ，在浏览器和 CAS Server 间通讯时使用，并且只能基于安全通道传输（ Https ），是 CAS Server 用来明确用户身份的凭证；
Ø Service ticket(ST) ：服务票据，服务的惟一标识码 , 由 CAS Server 发出（ Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 颁发给拥有 ST 凭证的服务， PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，获得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是将通过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 应用。 Web 应用负责维护 PGTIOU 与 PGT 之 间映射关系的内容表；
Ø Proxy Ticket (PT) ：是应用程序代理用户身份对目标程序进行访问的凭证；
其它说明如下：
Ø Ticket Granting ticket(TGT) ：票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交身份认证信息 (Credentials) ；
Ø Authentication service(AS) --------- 认证用服务，索取 Credentials ，发放 TGT ；
Ø Ticket-granting service (TGS) --------- 票据授权服务，索取 TGT ，发放 ST ；
Ø KDC( Key Distribution Center ) ---------- 密钥发放中心；
4. CAS 安全性CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie 。
4.1. TGC/PGT 安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问 **所有 **授权资源。 PGT 的角色跟 TGC 是一样的。
从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟。
4.2. ST/PT 安全性
ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：
1、 ST 只能使用一次
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket ，从而可以确保一个 Service Ticket 不被使用两次。
2、 ST 在一段时间内失效
CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。
3、 ST 是基于随机数生成的
ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的服务。