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服务端中。要实现上图的分布式部署，将其存入共用的数据库即可。