Cas 系统简介
CAS 系统
单点登录
单点登录（SSO）的全称是 Single Sign On，是指在应用群中只需要登录一次就可以访问该应用群中所有应用的技术。Cas 是 SSO 的一种实现。
CAS 基础架构
本文所讨论的 Cas 系统版本是 5.1.x
1. CAS 系统分为两部分：
- CAS server: 基于 Spring 框架构建，主要用于让通过认证的用户访问注册了的系统（CAS client）,认证用户的方式通过分发和验证票据（TGT）。
- CAS client：通常在 CAS server 上注册了应用系统。这些应用系统都可以通过 CAS server 支持的协议与 CAS server 进行通信。
2. CAS 支持的协议如下：
- CAS 1, 2, 3
- SAML 1.1, 2
- OpenID Connect
- OpenID
- OAuth 2.0
- WS Federation
3. CAS server 主要组成部分
- Web(SpringMVC/SpringWebflow)
- Ticketing
- Authentication
Web 部分主要是与外部进行交互，包括登录页面或者登录的接口，Ticketing 部分主要用于票据的分发和验证，Authentication 部分主要用于登录的验证过程。在通过验证之后，用户就可以拿到 CAS server 分发的（TGT） 票据。用户拿到票据后，在访问其他的系统时不需要再次进行登录，只需要到 CAS server 验证票据即可。
Cas 安装
Cas 系统的安装分为两部分，一部分是 Cas Server 的安装，一部分是 Cas client 的安装。Cas Server 是一个独立的 Java Web 应用。而 Cas client 则支持不同的语言，可以嵌入到不同语言的应用中去。
官方提供的 Cas Server 是开箱即用的，如果没有需要定制的认证逻辑，基本可以使用官方包直接部署，官方称这种方式为 Overlay 部署方式。具体可以基于 Docker 部署和 Servlet 容器（Tomcat等）进行部署。
如果采用官方提供的包进行部署，只需要在配置文件里面修改一下数据库账号和密码就可以。
在部署了 Cas server 系统之后，还需要部署一个 cas-managment Web 应用，这个应用用来管理在 Cas server 中注册的应用。
Web 端
Cas Server 面向用户的模块采用了 Spring 框架，提供了 SpringMVC 和 SpringWebflow 两种选择。
Cas 认证过程
Cas 1.0
下面这张图展示了 Cas 系统的工作方式，首先，用户在首次访问系统群中的一个应用1时，会跳转到 Cas 系统的登录页面。在用户名和密码得到 Cas 系统的认证了之后，就会拿到 Cas 系统生成一个票据 TGT（Ticket Granting Ticket），然后就会跳转回应用1，应用1会去 Cas server 验证票据的有效性，如果有效就可以访问应用1了。
接下来如果用户关闭了应用1，在票据的有效期内再次访问了应用1，那么应用这时候只会验证 cookie， 而不需要再次验证票据了。
但是如果应用此时访问了应用群里的应用2，那么还是需要先跳转到 Cas server 验证票据，验证通过后才会跳转到应用2。
Cas 2.0
以上的过程是标准的 Cas 认证过程，Cas 还支持通过代理的方式来实现的认证，也就是说，应用不需要直接和 Cas 系统进行通信，只需要和代理进行通信就行。但是产生的票据不是 TGT，在代理服务器上会产生一个 PGT（Proxy Granting Ticket）。在代理认证中，所有的应用不直接通过 Cas server 认证，而是与通过认证的代理应用进行交互。其他的认证的过程与直接通过 Cas server 基本没有差别，疼哦这种方式，可以完成非 Web 应用之间的单点登录。
通过上面的认证过程，也就完成了单点登录。那么登出功能自然也是要在一个应用中退出之后，在所有其他的应用中也需要退出。在退出的过程中，实际就是将 SSO session（一般存储在redis中） 删除的过程。
应用注册
每一个嵌入 Cas client 的应用都称之为 service，在 service 接入到 Cas server 之前，都需要在系统中进行注册。需要通过 cas-managment 应用进行注册。
参考文献: