CAS—认证原理

摘要：

以下是对SSO的简要介绍，重点介绍CAS认证过程。CASClient负责处理对客户端受保护资源的访问请求。当需要

　　CAS，Central Authentication Service—中央认证服务，是Yale 大学发起的一个企业级的、开源的项目。旨在为Web应用系统提供一种可靠的SSO解决方式。以下简介SSO，重点介绍CAS认证过程。

　　1.1   概念

　　SSO英文全称Single Sign On，是眼下比較流行的服务于企业业务整合的解决方式之中的一个， SSO 使得在多个应用系统中。用户仅仅须要登录一次 就能够訪问全部相互信任的应用系统。

　　1.2  角色

　　一般 SSO 体系主要角色有三种：

　　＊  User （多个）

　　＊ Web 应用（多个）

　　＊ SSO 认证中心（ 一个 ）

　　1.3  原则

　　SSO 实现模式一般包含下面三个原则：

　　＊  全部的认证登录都在 SSO 认证中心进行。

　　＊  SSO 认证中心通过一些方法来告诉 Web 应用当前訪问用户到底是不是已通过认证的用户；

　　＊  SSO 认证中心和全部的 Web 应用建立一种信任关系。也就是说 web 应用必须信任认证中心。（单点信任）

　　2.1  体系结构

　　　　从结构体系看，CAS 包含两部分： CAS Server 和 CAS Client 。

　　　　CAS Server负责完毕对用户的认证工作 ，会为用户签发两个重要的票据：登录票据（TGT）和服务票据（ST）来实现认证过程, CAS Server须要独立部署 。

　　　　CAS Client负责处理对client受保护资源的訪问请求，须要对请求方进行身份认证时。重定向到 CAS Server 进行认证。准确地来说，它以Filter 方式保护受保护的资源。对于訪问受保护资源的每一个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包括 ServiceTicket（服务票据。由 CAS Server发出用于标识目标服务）。

CAS Client 与受保护的client应用部署在一起。

　　由上可知，它符合SSO中的角色架构，例如以下：

　　＊  User （多个）

　　＊  Web 应用（多个CAS Client—与Web应用部署在一起）

　　＊  SSO 认证中心（ 一个CAS Server—独立部署）

　　2.2  核心票据

　　　　CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，当中TGT、ST是CAS1.0(基础模式)协议中就有的票据，PGT、PGTIOU、PT是CAS2.0(代理模式)协议中有的票据。

这里主要介绍CAS1.0—基础模式中的几种票据。

　　TGT（Ticket Grangting Ticket）

　　　　TGT是CAS为用户签发的登录票据。拥有了TGT，用户就能够证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值相应的用户信息。

用户在CAS认证成功后，生成一个TGT对象，放入自己的缓存（Session）。同一时候，CAS生成cookie（叫TGC。个人理解，事实上就是TGT的SessionId），写入浏览器。

TGT对象的ID就是cookie的值。当HTTP再次请求到来时。假设传过来的有CAS生成的cookie。则CAS以此cookie值（SessionId）为key查询缓存中有无TGT（Session）。假设有的话，则说明用户之前登录过，假设没有，则用户须要又一次登录。

 　　TGC （Ticket-granting cookie）

　　　　上面提到。CAS-Server生成TGT放入自己的Session中，而TGC就是这个Session的唯一标识（SessionId），以Cookie形式放到浏览器端。是CAS Server用来明白用户身份的凭证。

（假设你理解Session的存放原理的话就非常好理解）

  　　ST（ServiceTicket）

　　　　ST是CAS为用户签发的訪问某一服务票据。用户訪问service时，service发现用户没有ST。则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，假设用户的请求中包括cookie，则CAS会以此cookie值为key查询缓存中有无TGT，假设存在TGT，则用此TGT签发一个ST。返回给用户。

用户凭借ST去訪问service，service拿ST去CAS验证。验证通过后。同意用户訪问资源。

为了保证ST的安全性：ST 是基于随机生成的。没有规律性。

并且。CAS规定 ST 仅仅能存活一定的时间。然后 CAS Server 会让它失效。并且，CAS 协议规定ST仅仅能使用一次，不管 Service Ticket 验证是否成功， CASServer 都会清除服务端缓存中的该 Ticket 。从而能够确保一个 Service Ticket 不被使用两次。

　　2.3  认证过程

　　这里用一个终端，对两个CAS—Client的三次请求来说明CAS的认证过程，主要是TGT、TGC、ST等票据的传递。以及怎样实现的SSO。

　　例如以下图，前两次请求都是訪问的CAS—Client1。主要来说明TGT、TGC、ST等票据的作用；然后第三次请求訪问的是CAS—Client2。主要来说明怎样实现的SSO。

　　Request1

　　　　【第一步】终端第一次訪问CAS—Client1，AuthenticationFilter会截获此请求：1、首先，检測本地Session没有缓存实用户信息；2、然后，检測到请求信息中没有ST；3、所以，CAS—Client1将请求重定向到CAS—Server。并传递 Service （也就是要訪问的目的资源地址，以便登录成功过后转回该地址），例：【https://cas:8443/cas/login?service=http0%3A8081%2F】

　　　　【第二步】终端第一次訪问CAS—Server：1、CAS—Server检測到请求信息中没有TGC，所以跳转到自己的登录页；2、终端输入username、password登录CAS—Server，认证成功后，CAS—Server会生成登录票据—TGT（集成了用户信息与ST），并随机生成一个服务票据—ST与CAS会话标识—TGC。

TGT实际上就是Session，而TGC就是这标识这个Session存到Cookie中的SessionID；ST即，依据Service生成Ticket。3、然后，CAS—Server会将Ticket加在url 后面，然后将请求redirect 回客户web 应用，比如URL为【http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZ】

　　　　【第三步】这时。终端携带ticket再次请求CAS—Client1：1、这时客户端的AuthenticationFilter看到ticket 參数后，会跳过。由其后面的TicketValidationFilter 处理；2、TicketValidationFilter 会利用httpclient工具訪问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口。由此接口验证ticket 的有效性。即向CAS—Server验证ST的有效性。3、TicketValidationFilter假设得到验证成功的消息。就会把用户信息写入web 应用的session里。至此为止，SSO 会话就建立起来了。

　　Request2

　　　　上面说了SSO 会话已经建立起来了，这时用户在同一浏览器里第二次訪问此web 应用（CAS—Client1）时，AuthenticationFilter会在session 里读取到用户信息，这就代表用户已成功登录，所以就不会去CAS 认证了。

　　Request3

　　　　【第一步】与Request1是全然一样的，例如以下：终端第一次訪问CAS—Client2，AuthenticationFilter会截获此请求：1、首先，检測本地Session没有缓存实用户信息。2、然后。检測到请求信息中没有ST；3、所以，CAS—Client1将请求重定向到CAS—Server，并传递 Service （也就是要訪问的目的资源地址。以便登录成功过后转回该地址）。例：【https://cas:8443/cas/login?service=http0%3A8081%2F】

　　　　【第二步】然后。终端第二次訪问CAS—Server：此时，Request中会带有上次生成的TGC，然后依据TGC（SessionID）去查找是否有相应的TGT（Session），假设有，代表此用户已成功登录过，所以此时用户不必再去登录页登录（SSO的体现）。而CAS—Server会直接用找到的TGT签发一个ST，然后重定向到CAS—Client2。剩下的如Request1中的【第三步】就全然一样了。

　　　　CAS认证过程中的核心概念即是几个【票据】，实际上事实上就是1个Cookie和N个Session。包含CAS1.0（基础模式）的TGT、ST、TGC。以及CAS2.0（代理模式）的PGT、PT、PGTIOU等。认证过程，即是这几个票据的传递与对照验证的过程。