原地址：https://blog.csdn.net/hejingyuan6/article/details/44277023
一、概念：
    单点登录（Single Sign On）：简称为SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
    CAS（Central Authentication Service）：中央认证服务。CAS(Central Authentication Service)是一款不错的针对 Web应用的单点登录框架。
讲解CAS之前先来学习两个基本术语
二、术语解释：
1、TGC：Ticket-granting cookie，存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息。
2、TGT：ticket granting ticket，TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT。
3、ST：service ticket，CAS为用户签发的访问某一service的票据，ST是TGT签发的。
4、PGT：proxy granting ticket，代理模式下的TGT
5、PT：proxy ticket，代理模式下的ST
6、service：在cas系统中，接入的各个子系统叫服务。因为对普通用户来说，每一个接入到cas认证中心的子系统都提供特定的服务比如商城、bbs等，大家都听过软件即服务，平台即服务，这样理解service就通顺了
SaaS：Software-as-a-Service，软件即服务
PaaS：Platform as a Service，平台即服务
7、credentials，凭证，即待认证的用户的信息载体，如用户名+密码
8、Principal，当事人，即认证之后返回的已认证的当事人的信息载体，默认只返回用户ID即用户名。
9、Authentication表示一个完成的认证请求，当然，结果可能是凭证有效或无效，他有一个method可以获取
三、深入CAS
    从结构上看，CAS包含两个部分：
    CAS Server：CASServer 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 /密码等凭证 (Credentials) 。
    CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。
    CASClient 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
    CAS最基本的协议过程：

    CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护 Web应用的受保护资源，过滤从客户端过来的每一个 Web 请求
    步骤详解：
    （step 1）Web浏览器访问CAS Client，无session并且无票据(ST)，定向到CASServer
    （step 2）又因为浏览器中并没有cookie，故服务端拿不到TGC，因此需要重新登录
    （Step 3）是用户认证过程，如果用户提供了正确的CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，认证成功后，CAS生成cookie（叫TGC），写入浏览器，同时生成一个TGT对象，再根据TGT发放票据ST，并且重定向用户到CAS Client（附带刚才产生的ServiceTicket）， Service Ticket 是不可以伪造
    （step4）注：ST前半部分为登录url，后半部分为我客户端要访问的页面地址，只有当登录成功才会直接转向客户端访问的页面
    （Step 5）拿着ST去 CAS Server验证一下，验证成功返回用户信息（step6）
    注：收到ST后，为什么还要验证呢？
    因为CAS知道这个用户已经登录过了，但是对于这个项目来说，我并不知道这个用户已经登录过了，故需要验证
    当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
    1)如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；
    2)如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
CAS 请求认证时序图如下：

    １. CAS服务端登录时处理：
    第一步：cas往浏览器增加cookie（TGC）
    CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-grantingcookie”，用来表明用户已经成功地登录。
    这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。用于以后其它应用客户端登录。
    第二步：cas同时创建一个ticket(ST)重定向到原来的cas客户端。
    认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。
    ２. CAS 客户端应用Ａ的处理
    第一步：收到ticket后，向cas提交验证ticket。
    第二步：ticket验证后创建session
    以后登录此应用时，没有ticket，但IE。能提供session,从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用。
    到此为止，CAS会记录用户已在应用Ａ已经登录。
    ３. 用户登录到应用Ｂ是如何处理
    用户进入应用Ｂ时，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。然后，CAS同样给出新的ticket重定向应用Ｂ给cas验证（流程同应用Ａ验证方式），如果验证成功则应用Ｂ创建session记录CASReceipt信息到session中，以后凭此session登录应用Ｂ。
    原理：１个cookie+Ｎ个session
    CAS创建cookie在所有应用中登录时cas使用,各应用通过在IE创建各自的session来标识应用是否已经登录。
    Cookie:在cas为各应用登录时使用，实现了只须一次录入用户密码
    Session:各应用会创建自己的session表示是否登录
    具体描述一下客户端消息流程
    1.第一次访问http://localhost:8080/a,
    CLIENT：没票据且SESSION中没有消息所以跳转至CAS
    CAS：拿不到TGC故要求用户登录
    2. 认证成功后回跳
    CAS：通过TGT生成ST发给客户端，客户端保存TGC，并重定向到http://localhost:8080/a
    CLIENT：带有票据(ST)所以不跳转只是后台发给CAS验证票据（浏览器中无法看到这一过程）
    3.第一次访问http://localhost:8080/b
    CLIENT：没票据且SESSION中没有消息所以跳转至CAS
    CAS：从客户端取出TGC，如果TGC有效则给用户ST并后台验证ST，从而SSO。【如果失效重登录或注销时，怎么通知其它系统更新SESSION信息呢？？TicketGrantingTicketImpl类grantServiceTicket方法里this.services.put(id,service);可见CAS端已经记录了当前登录的子系统】
    单点退出：
    4.再次访问http://localhost:8080/a
    CLIENT：没票据但是SESSION中有消息故不跳转也不用发CAS验证票据，允许用户访问