CAS SSO企业单点登录系统——基础概念

一、基本概念

1. SSO单点登录

​ 通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。

​ 举个栗子，当你在百度搜索的首页进行了登录，那么你进入百度的其他应用，比如贴吧，hao123主页等应用，你就会发现你已登录状态，无需再额外登录。

​ 从这里也可以看出，一个单点登录系统涉及到了几个部分，用户，多个企业应用（比如贴吧，百度视频等），一个SSO系统（可能不同应用的登录界面会有不同，比如百度视频的登录界面跟其他的就不同）

1.1. SSO原理

• 单系统登录

  无状态协议http

  ​ 意味着每次的http请求对服务器来说都是一次单独的请求，但是我们必须保护服务器资源，需要对每次的请求进行合法与否的判断，需要对请求进行鉴别，响应合法的请求，忽略非法请求，既然http是无状态的，那么就必须在浏览器跟服务器之间共同维护一个状态（http协议之外），这个就是会话机制；

  Cookie&Session

  ​ 在浏览器第一次请求服务器时，服务端会创建一个会话（session），并将会话的id返回给浏览器，浏览器自动存储该会话id（cookie），并在后续的请求中自动带上这个会话id给服务器，服务器通过请求的会话id就可以知道当前是哪个用户；

• 多系统登录

  ​ 企业自身的多系统应用对用户而言，是一个整体，所以不能是每个系统单独进行登录，登出，用户访问web系统的整个应用群与访问单个系统一样，登录/注销只要一次就够了。

  ​ 按照Cookie&Session的解决方案，理论上，我们可以通过共享cookie&session的方式实现，但需要注意到以下的事项：

  1. 所有web应用的域名统一在一个顶级域名下，因为cookie是有域限制的，在第一子系统登录后，session的会话id需要存储在顶级域名下（cookie中的path设置）；

  2. 所有的web应用服务器，需要统一，不然cookie的key值不同（对tomcat来说，是 JSESSIONID），无法维持会话；

  3. 这种方式无法支持跨语言平台；

  4. 另外服务器端的session需要通过共享实现，比如session放在redis等缓存；

  ​ 因此，我们需要一种全新的登录方式来实现多系统应用集群的登录/注销，这就是单点登录。

• SSO原理

  ​ SSO是有一个独立的认证中心，该认证中心作为一个子系统（服务），提供用户登录入口，sso验证用户身份没有问题，创建授权令牌，包括全局会话，在接下来的应用跳转过程中，授权令牌作为参数传送给各个子系统应用，子系统应用拿到令牌后，通过sso认证中心验证令牌的正确性，并建立起局部的会话。

  SSO登录
  
  SSO注销

sso认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作

1.2 什么是CAS

1.2.1 简介

Project: https://www.apereo.org/projects/cas/

Github: https://github.com/apereo/cas

Apereo的一个开源项目。源于耶鲁大学实验室的统一认证服务，全称Central Authentication Service

Apache License 2.0协议

企业（集群）单点登录，统一认证，其他类似项目，还有Keycloak(https://github.com/keycloak/keycloak/)

同名的CAS还代表了CAS协议，是一种开放的、文档丰富的身份验证协议

多种协议支持，包括CAS (v1、v2、v3)，SAML（V1，V2）, OAuth2，OpenID，REST等

可插拔的各种认证方式支持，包括JAAS，LDAP，Database，AD，X.509, 2-factor, JWT等

同时也支持JPA、MycCache、Apache IGITE、MangGDB、ReDIS等实现高可用多个集群部署

各种丰富的客户端，像常见的Java、Python、Node、PHP、C#、Perl等等

由JSON，LDAP，YAML，Apache Cassandra，JPA，Couchbase，MongoDb，DynamoDb，Redis等支持的应用程序注册

管理用户界面，用于管理日志记录，监视，统计信息，配置，客户端注册等

1.2.2 体系结构

系统组成

​ CAS服务器和客户端组成CAS系统体系结构的两个物理组件，它们通过各种协议进行通信。

服务端

​ CAS服务器是在Spring框架上构建的Java应用程序，其主要职责是通过发行和验证票证来认证用户并授予对启用CAS的服务（通常称为CAS客户端）的访问权限。当服务器在成功登录后向用户颁发授予票据的票证（TGT）时，将创建SSO会话。应用户的请求，使用TGT作为令牌，通过浏览器重定向将服务票证（ST）发行给服务。随后通过反向通道通信在CAS服务器上验证ST。这些交互在CAS协议文档中进行了详细描述。

客户端

​ “ CAS客户端”一词在其常见用法中具有两种不同的含义。CAS客户端是可以通过支持的协议与服务器通信的任何启用CAS的应用程序。CAS客户端也是一个软件包，可以与各种软件平台和应用程序集成，以便通过某种身份验证协议（例如CAS，SAML，OAuth）与CAS服务器进行通信。

1.2.3 CAS协议

​ CAS协议是一种简单且功能强大的基于票证的协议。完整的协议规范可以在这里找到

关键概念是：

• TGCTicket Granted Cookie , 以Cookie的形式保存在客户端浏览器所占用的内存中(Cookie值)，它存储的值是TGT对象的ID；
• TGT “Ticket Granting Ticket”，用户在CAS认证成功后，CAS生成TGC，写入浏览器；同时生成一个TGT对象，放入自己的缓存（以Key/Value方式），key为ID存入GTC，Value封装了登录用户的相关信息；
• ST（Service Ticket），作为参数在GET请求的URL中，代表由CAS服务器授予特定用户访问CASified应用程序的权限，由TGT签发

协议登录流程