一、什么是单点登录（SSO）
单点登录主要用于多系统集成，即在多个系统中，用户只需要到一个中央服务器登录一次即可访问这些系统中的任何一个，无须多次登录。
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
二、web系统如何实现单点登录
目前已经有了成熟的单点登录实现方案，比如CAS，我们只要在web系统中应用单点登录方案CAS即可。(主要涉及到注册登录验证等模块的改动)。
三、什么是CAS
CAS (Central Authentication Service) 是耶鲁 Yale 大学发起的一个java开源项目，旨在为 Web应用系统提供一种可靠的 单点登录 解决方案（ Web SSO ）， CAS 具有以下特点：
-
- 开源的企业级单点登录解决方案；
- CAS Server 为需要独立部署的 Web 应用----一个独立的Web应用程序(cas.war)。 ；
- CAS Client 支持非常多的客户端 ( 指单点登录系统中的各个 Web 应用 ) ，包括 Java, .Net, PHP, Perl, 等。
CAS在2004年12月成立Jasig项目，所以也叫JA-SIG CAS。
官网1：https://apereo.github.io/cas/5.2.x/index.html
官网2： https://www.apereo.org/projects/cas/about-cas
论坛：http://jasig.275507.n4.nabble.com/Jasig-CAS-f275508.html
github：https://github.com/apereo/cas
开发者快捷资源：http://developer.jasig.org/
下载链接：https://www.apereo.org/projects/cas/download-cas
官网开发文档：https://apereo.github.io/cas/5.2.x/installation/Configuring-Commandline-Shell.html
中文开发文档：http://www.cassso-china.cn/apereo_github_cas_5.2//apereo.github.io/cas/5.2.x/
四、CAS原理
从结构上看， CAS 包含两个部分： CAS Server 和 CAS Client 。
1、CAS Server
CAS Server 需要独立部署，主要负责对用户的认证工作， 它会处理用户名 / 密码等凭证 (Credentials) 。
CAS Server 负责完成对用户的认证工作， 需要独立部署。并且有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。
CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式， CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
2、CAS Client
CAS Client 部署在客户端， 负责处理本地 Web 应用（客户端）受保护资源的访问请求，并且当需要对请求方进行身份认证时，重定向到 CAS Server 进行认证 。
CAS Client 负责部署在客户端（注意，是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。
目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。
3、CAS相关词汇和概念
(后面代码小节会详细介绍，这里初步了解即可)
TGC(ticket-granting cookie) —— 授权的票据证明，由 CAS Server 通过 SSL 方式发送给终端用户；
KDC( Key Distribution Center ) —— 密钥发放中心；
ST (Service ticket) —— 服务票据， 由 KDC 的 TGS 发放， ST 只能被尝试验证一次。 任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 (Applications) 。 如果能正确接收 Service Ticket ，说明在 CASClient-CASServer 之间的信任关系已经被正确建立起来，通常为一张数字加密的证书；
Ticket Granting tieckt(TGT) —— 票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交 Credentials （凭证或身份认证信息 ) ；
Authentication Service (AS) —— 认证服务，索取 Crendential ，发放 TGT ；
Ticket-Granting Service (TGS) —— 票据授权服务，索取 TGT ，发放 ST 。
4、CAS协议和工作流程
下图是 CAS 基础协议：
（1）CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求， CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5 ， 6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
（2）在该协议中，所有与 CAS 的交互均采用 SSL 协议确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
（3）CAS 如何实现 SSO
当用户访问另一服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
1) 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；
2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。
原文：https://blog.csdn.net/zzq900503/article/details/54646828