首页

# 前言

因为工作上最近接触到 CAS ，找时间把 CAS 的知识进行整理与总结，通过整理系列笔记加深自己对 CAS 的理解，如果文中存在错误，望大家指正。

# 简介

CAS 是 Apereo Central Authentication Service 项目的简称，CAS 是一个企业多语言单点登录解决方案和网络身份提供者，并试图成为满足您身份验证和授权需求的综合平台。CAS 是一个开放且有据可查的身份验证协议。该协议的主要实现是此处托管的同名开源 Java 服务器组件，支持大量附加身份验证协议和功能。

相关链接：

1. cas社区博客
	https://apereo.github.io
2. cas源码地址
	https://github.com/apereo/cas
3. cas官网地址
	https://www.apereo.org/projects/cas
4. cas官方文档
	https://apereo.github.io/cas/index.html
5. cas构建过程
	https://apereo.github.io/cas/developer/Build-Process.html
6. cas架构
	https://apereo.github.io/cas/6.5.x/planning/Architecture.html

# 特征

CAS 项目支持以下功能：

  • CAS v1、v2 和 v3 协议
  • SAML v1 和 v2 协议
  • OAuth v2 协议
  • OpenID 和 OpenID 连接协议
  • WS-Federation 被动请求者协议
  • 通过 JAAS、LDAP、RDBMS、X.509、Radius、SPNEGO、JWT、Remote、Apache Cassandra、Trusted、BASIC、Apache Shiro、MongoDb、Pac4J 等进行身份验证。
  • 将身份验证委托给 WS-FED、Facebook、Twitter、SAML IdP、OpenID、OpenID Connect、CAS 等。
  • 通过 ABAC、时间 / 日期、REST、Internet2 的 Grouper 等进行授权。
  • 通过 Hazelcast、Ehcache、JPA、Apache Cassandra、Memcached、Apache Ignite、MongoDb、Redis、DynamoDb、Couchbase 等进行 HA 集群部署。
  • 由 JSON、LDAP、YAML、Apache Cassandra、JPA、Couchbase、MongoDb、DynamoDb、Redis 等支持的应用程序注册。
  • 通过 Duo Security、YubiKey、RSA、Google Authenticator、U2F、WebAuthn 等进行多因素身份验证。
  • 用于管理日志记录、监控、统计、配置、客户端注册等的管理 UI。
  • 全局和每个应用程序的用户界面主题和品牌。
  • 密码管理和密码策略执行。
  • 使用 Apache Tomcat、Jetty、Undertow 的部署选项，打包并作为 Docker 容器运行。

CAS 的基础建立在：Spring Boot 和 Spring Cloud 之上。

# 构建

要在本地构建项目，请遵循本指南。发布时间表可在此处获得。

# CAS 基本原理

# 结构

CAS 结构中主要分两部分，一部分是 CAS Server，另一部分是 CAS Client，其中 CAS Server 主要负责完成对用户的认证工作，需要独立部署，CAS Server 会处理用户名密码等凭证（Credentials）；CAS Client 负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证（原则上客户端应用不再接受任何的用户名密码等 Credentials）。

# 协议

CAS 协议是一个简单而强大的基于票据的协议，它涉及一个或多个客户端和一台服务器。CAS 通过 TGT（Ticket Granting Ticket）来获取 ST（Service Ticket），通过 ST 来访问具体服务。

TGC（Ticket-granting cookie）：存放用户身份认证凭证 cookie，在浏览器和 CAS Server 用来明确用户身份的凭证。
ST（Service Ticket）：CAS 服务器通过浏览器分发给客户端服务器的票据，一个特定服务只能有一个唯一的 ST 。

CAS 基本协议过程：

  1. 访问服务： CAS 客户端发送请求访问应用系统提供的服务资源。
  2. 定向认证： CAS 客户端重定向用户请求到中心认证服务器。
  3. 用户认证： 用户进行身份认证。
  4. 发放票据： CAS 服务器会产生一个随机的 Service Ticket 。
  5. 验证票据： CAS 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
  6. 用户信息： CAS 服务器验证票据通过后，传输用户认证结果信息给客户端。

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTPS 请求中是否包含请求 Service Ticket（ST 上图中的 Ticket） ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。

# 单点流程

CAS 官方单点登录流程：

在 CAS 协议流程图中，SSO 令牌就是 CAS 中的 ST (Service Ticket)。

首先用户访问受保护的资源，由于权限没有认证通过，所以会把请求的 URL 作为请求参数跳转到 CAS 认证中心，CAS 认证中心发现没有 SSO Session，所以弹出登录页面，用户输入认证信息，提交到 CAS 认证中心进行信息认证，如果信息正确，CAS 认证中心就会创建一个 SSO Session 和 CAS TGC Cookie，这个 CAS TGC Cookie 包含了 TGT，而用户 Session 则以 TGT 为 key 创建，同时服务端会分发一个 ST 返回给用户，用户拿到了 ST 后，访问带参数 ST 的应用地址，应用接收到 ST 后将 ST 再次发送给 CAS 认证中心，CAS 认证中心对 ST 进行校验，同时判断相应的 Cookie（包含 TGT ）是否正确（通过先前设定的 key ），判断 ST 是否是有效的，结果会返回一个包含成功信息的 XML 给应用。应用在建立相应的 Session 和 Cookie 跳转到浏览器，用户再通过浏览器带 Cookie 去应用访问受保护的资源地址，Cookie 和后端 Session 验证成功便可以成功访问到信息。

第二次访问应用时，浏览器就会携带相应的 Cookie 信息，后台 Session 验证用户是否登录，与一般单系统应用登录模式一样。

当我们访问其他的应用，与前面的步骤也是基本相同，首先用户访问受保护的资源，跳转回浏览器，浏览器含有先前登录的 CAS TGC Cookie，CAS TGC Cookie 包含了 TGT 并发送到 CAS 认证中心，CAS 认证中心校验 TGT 是否有效，如果有效分发浏览器一个带 ST 参数的资源地址 URL，应用程序拿到 ST 后，再发送给 CAS 认证中心，如果认证了 ST 有效后，结果会返回一个包含成功信息的 XML 给应用。同样的步骤，应用在建立相应的 Session 和 Cookie 跳转到浏览器，用户再通过浏览器带 Cookie 去应用访问受保护的资源地址，验证 Session 成功便可以成功访问到信息。

未完待续...