sso cas4.0改造历程--初识篇

前言：

随着用户量的增加以及各种需求的调整，cas的功能免不了需要做各种各样的改造。

简单的：页面维护，样式修改，docker的分环境打包、登陆流程的添加（加个用户信息记录或者添加验证码）。

复杂些的：分布式部署的实现、https改造与多客户端联调。

针对做过的这些改造，下面分篇来讲一讲自己的收获，分享一下遇到的坑以及解决方案。有不对的希望能帮忙指正，希望能给以后处理的人少挖些坑吧。

资源：

CAS( Central Authentication Service)是耶鲁大学的开源项目，旨在实现企业应用单点登录。

其官网 ：https://www.ap ereo.org/

基本概念：

  TGC （Ticket-granting cookie）

存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证。

TGT（Ticket Grangting Ticket）

TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie（叫TGC），写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

ST（Service Ticket）

ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

大体流程：

事实上当大家对spring-webflow有了解以后看，查看src\main\webapp\WEB-INF\login-webflow.xml，就可以自己把这个流程图画出来了。对应的登出流程就在src\main\webapp\WEB-INF\logout-webflow.xml下面。

需要注意一下几点：

关于流程

1、app端有session时，无需再次请求cas服务端（实线部分的流程即可）。

2、app端有st，则直接校验即可（无须重定向到cas服务端获取st）。

3、只有当1、2都不满足，或者校验不通过时，才会唤起输入用户名和密码的页面。

4、cas是集成了spring-webflow的，而对应的信息又保存在cas_server端的session中。所以要分布式部署的话，不能忘了session的共享。

关于票据

1、TGC (Ticket-granting cookie),是存放在浏览器中的，从它是名字就能判断出来。

2、包含用户信息的session保存在app服务端和cas的服务端

3、TGT（Ticket-granting Ticket），ST(Service Ticket)存放在cas服务端中。要实现上图的分布式部署，将其存入共用的数据库即可。