前一段时间，公司项目因为要与其他项目之间进行集成，弄成一个整体的大项目，因为各个项目都是老项目了，每一个项目都有一个自己的登录过滤机制，这时的需求就变成了只需一次登录，就可以登录进去其他子项目，不用每次访问其他项目都需要登录一次。
这个任务就交给了我这个刚毕业参加工作没多久的身上，说实话，对我来说还是挺难的。后来在网上查找各种资料，就选定了用的比较多的成熟框架 CAS 。在实际开发中，也碰到了很多各种各样的问题，在这里把自己对 CAS 的理解，碰到的问题总结一下，也希望能够帮助到更多的人。
单点登录
单点登录就是一次登录过后，再没有退出或者清缓存的情况下，用户再访问其他集成了这个功能的项目时，就不需要进行重复的登录操作，这样会大大的方便用户的使用。如果每次都需要用户登录一遍，估计这个项目也就没多少人用了，所以单点登录这个功能是非常必要的。
CAS
CAS 是耶鲁大学开源的一个单点登录框架，旨在为 web 应用系统提供一个安全可靠的单点登录框架，最终，在我们公司的项目中选择了使用 CAS 框架。
名词解释
在我们了解 CAS 的工作原理之前，我们应该首先了解下在 CAS 里面的一些概念，这样对我们理解 CAS 有一个更好的帮助。
ST：Service Ticket，服务票据，服务的唯一标识码，由 CAS 认证中心生成，返回给用户，这时 service 拿到 ST 后，又会去到 CAS 验证中心去验证，如果验证成功，则允许用户访问资源。
TGC：Ticket Granting Cookie，CAS 系统用来识别用户身份的凭证。
TGT：Ticket Grangting Ticket，票据授权票据，获取这个 TGT 后才能申请服务票据（ST），用户如果在 CA S系统认证成功之后，就会生成 TGC 写入浏览器，同时也生成一个 TGT，TGT 对象的id就是 cookie 值。之后每次请求过来通过此 cookie 来从缓存获取 TGT，就不用提交身份认证信息（Credentials）。
工作过程
了解到上面这些名词的概念之后，我们来看看下面这一张图，能更形象的解释 CAS 的工作流程。
访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
用户认证：用户身份认证。
发放票据： SSO 服务器会产生一个随机的 Service Ticket 。
验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。
CAS 分为服务端和客户端，每一个服务就相当于是一个客户端，当用户去访问一个没有经过登录的服务时，会重定向到 CAS Server 提供的登录界面，不过这个界面我们也可以自定义，也可以使用原客户端的登录界面，需要我们自己去做一些修改。输入完用户名和密码后，CAS Server 验证成功后，会向浏览器增加一个加密过的 cookie，也就是 TGC ，用来表明用户已经成功登录，这里保存了用户的信息，以供其他客户端使用。同时会重定向到客户端并且创建一个随机的，具有唯一标识的 Ticket，也就是 ST，CAS 将 ST 与登录成功的用户和服务联系在一起，只使用一次，使用过后立刻失效。客户端接收到 ST 后，会进行校验，校验成功后，创建 Session，放开相关资源供用户使用。当用户去访问其他服务时，这时用户已经成功登录过了，这时任然会重定向到 CAS Server 端，但是不需要用户再输入用户名和密码了，而是首先寻找 Cookie，根据其中的信息，进行登录，CAS 同样给出新的 ST 重定向到 Server 端校验，校验成功则创建 Session，允许访问。
看到这里，我们大致能够明白 CAS 的工作过程，第一步用户访问应用服务器重定向到认证服务器（CAS Server），输入用户名和密码，验证成功后，建立浏览器与认证服务器（CAS Server）之间的信任，但是浏览器与应用服务器之间并没有建立信任，所以 ST 是认证服务器返回的，应用服务器拿到这个 ST 后，再去认证服务器验证是否合法，如果合法，则建立应用服务器与认证服务器之间的信任。TGC 主要的作用是用于单点登录，当浏览器访问应用服务器2的时候，也会重定向到认证服务器，这时 TGC 存在，不需要输入用户名和密码，直接返回 ST，继续验证是否合法，成功则允许访问。
CAS 的工作过程我们都了解了，接下来就是在自己项目的实际配置了，接下来我会继续分享我在项目中实际应用的情况，希望能够帮助到大家，同时对我自己也是一次关于 CAS 使用的总结。
