关于单点登录SSO那些事儿

Posted 2021-04-27 自动化测试笔记

前言

由于新做的代码变更行数统计系统需要给不同的人分配不同的权限，所以集成了公司的统一登录系统。顺便学习了一下其中的原理，将自己从网上查的资料和自己的理解整理如下。

我们在登录OA，DM后台或者TM后台系统时都会跳转到一个包含有汽车之家的登录页面的系统进行登录认证，当我们用OA密码登录成功后就有跳转回我们想登录的系统，这个过程究竟是怎么回事，其中的原理是什么？

想要了解这个过程，需要先了解两个概念：SSO和CAS

SSO是什么?

SSO英文全称Single Sign On，即单点登录。在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。

CAS又是什么？

CAS是Central Authentication Service的缩写，即中央认证服务，一种独立开始指令协议。CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

总的来说（个人理解），SSO其实是一种需求，即用户只需要登录一次就可以访问所有相互信任的应用系统，我们可以使用CAS这种技术方案将其实现，目前我们公司一些后台系统中的登录功能其实就是通过这种技术实现的，例如：OA、DM后台、线索开放平台广告/媒体/数据后台等。

那么CAS的原理又是怎么回事呢？

从架构体系上看，CAS包含Server端和Client端。

CAS Server负责完成对用户的认证工作 ，会为用户签发两个重要的票据：登录票据（TGT）和服务票据（ST）来实现认证过程, CAS Server已经由汽车之家汽车人部门为我们部署好了 。

CAS Client负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。准确地来说，它以Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 ServiceTicket（服务票据，由 CAS Server发出用于标识目标服务）。CAS Client 与DM后台、OA等需要登录保护的系统集成。

由上可知，它符合SSO中的角色架构，如下：

• 多用户

• 多web应用

• SSO认证中心（ 一个CAS Server—独立部署）

票据（Ticket）

CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0(基础模式)协议中就有的票据，PGT、PGTIOU、PT是CAS2.0(代理模式)协议中有的票据。这里主要介绍CAS1.0—基础模式中的几种票据。

TGT（Ticket Grangting Ticket）

TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，生成一个TGT对象，放入自己的缓存（Session）；同时，CAS生成cookie（叫TGC，个人理解，其实就是TGT的SessionId），写入浏览器。TGT对象的ID就是cookie的值，当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值（SessionId）为key查询缓存中有无TGT（Session），如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

TGC （Ticket-granting cookie）

上面提到，CAS-Server生成TGT放入自己的Session中，而TGC就是这个Session的唯一标识（SessionId），以Cookie形式放到浏览器端，是CAS Server用来明确用户身份的凭证。（如果你理解Session的存放原理的话就很好理解）

ST（ServiceTicket）

ST是CAS为用户签发的访问某一服务票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

为了保证ST的安全性：ST 是基于随机生成的，没有规律性。而且，CAS规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。而且，CAS 协议规定ST只能使用一次，无论 Service Ticket 验证是否成功， CASServer 都会清除服务端缓存中的该 Ticket ，从而可以确保一个 Service Ticket 不被使用两次。

认证过程

这里用一个终端（可以理解成浏览器），对两个CAS—Client（理解成一个是线索开放平台管理后台，一个是DM后台）的三次请求来说明CAS的认证过程，主要是TGT、TGC、ST等票据的传递，以及如何实现的SSO。

如下图，前两次请求都是访问的CAS—Client1，主要来说明TGT、TGC、ST等票据的作用；然后第三次请求访问的是CAS—Client2，主要来说明如何实现的SSO。

Request1

【第二步】终端第一次访问CAS—Server：1、CAS—Server检测到请求信息中没有TGC，所以跳转到自己的登录页；2、终端输入用户名、密码登录CAS—Server，认证成功后，CAS—Server会生成登录票据—TGT（集成了用户信息与ST），并随机生成一个服务票据—ST与CAS会话标识—TGC。TGT实际上就是Session，而TGC就是这标识这个Session存到Cookie中的SessionID；ST即，根据Service生成Ticket。3、然后，CAS—Server会将Ticket加在url 后面，然后将请求redirect 回客户web 应用，例如URL为【http://f2.dealeradvadmin.autohome.com.cn/cas?ticket=ST-1878652-gM3d6FjWHlzELUgYc6sy-cas01.example.org】

【第三步】这时，终端携带ticket再次请求CAS—Client1：1、这时客户端的AuthenticationFilter看到ticket 参数后，会跳过，由其后面的TicketValidationFilter 处理；2、TicketValidationFilter 会利用httpclient工具访问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，即向CAS—Server验证ST的有效性。3、TicketValidationFilter如果得到验证成功的消息，就会把用户信息写入web 应用的session里。至此为止，SSO 会话就建立起来了。

Request2

上面说了SSO 会话已经建立起来了，这时用户在同一浏览器里第二次访问此web 应用（CAS—Client1）时，AuthenticationFilter会在session 里读取到用户信息，这就代表用户已成功登录，所以就不会去CAS 认证了。

Request3

【第二步】然后，终端第二次访问CAS—Server：此时，Request中会带有上次生成的TGC，然后根据TGC（SessionID）去查找是否有对应的TGT（Session），如果有，代表此用户已成功登录过，所以此时用户不必再去登录页登录（SSO的体现），而CAS—Server会直接用找到的TGT签发一个ST，然后重定向到CAS—Client2，剩下的如Request1中的【第三步】就完全一样了。

总结

CAS的SSO实现方式可简化理解为：1个Cookie和N个Session。CAS Server创建cookie，在所有应用认证时使用，各应用通过创建各自的Session来标识用户是否已登录。

用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在session里读取到用户信息，所以就不会去CAS Server认证。如果在此浏览器里访问别的web应用时，客户端应用中的过滤器在session里读取不到用户信息，就会去CAS Server的login接口认证，但这时CAS Server会读取到浏览器传来的cookie （ TGC ），所以 CAS Server不会要求用户去登录页面登录，只是会根据 service 参数生成一个Ticket ，然后再和web 应用做一个验证ticket的交互而已。

CAS认证过程中的核心概念即是几个【票据】，实际上其实就是1个Cookie和N个Session。包括CAS1.0（基础模式）的TGT、ST、TGC；以及CAS2.0（代理模式）的PGT、PT、PGTIOU等。认证过程，即是这几个票据的传递与对比验证的过程。