CAS单点登录(一)——初识SSO

CAS单点登录(一)——初识SSO

 https://blog.csdn.net/anumbrella/article/details/80821486

 

前言：其实好早就想把CAS的这一套知识整合一下，在工作上也应用到了这块，只是最近才在工作上接触到CAS，所以刚好把这些知识总结一下。这块可能是一个比较大的模块知识点，所以会有多篇文章进行逐一展开，笔者会尽量抽空更新，当然如果文章中存在错误，期望大家指出。

一、初识CAS
首先我们来说一下CAS，CAS全称为Central Authentication Service即中央认证服务，是一个企业多语言单点登录的解决方案，并努力去成为一个身份验证和授权需求的综合平台。

CAS是由Yale大学发起的一个企业级的、开源的项目，旨在为Web应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。

CAS协议至少涉及三方：客户端Web浏览器，请求身份验证的Web应用程序和CAS服务器。 它也可能涉及后端服务，如数据库服务器，它没有自己的HTTP接口，但与Web应用程序进行通信。

主要特征：
多种的协议的支持，包括CAS (v1、v2、v3)、SAML(v1、v2)、OAuth、OpenID、OpenID Connect和WS-Federation Passive Requestor

多种认证机制，可以通过JAAS，LDAP，RDBMS，X.509，Radius，SPNEGO，JWT，Remote，Trusted，BASIC，Apache Shiro，MongoDB，Pac4J等进行身份验证

可以通过WS-FED，Facebook，Twitter，SAML IdP，OpenID，OpenID Connect，CAS等代理委派认证

多种形式的授权包括ABAC, Time/Date, REST, Internet2’s Grouper等

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

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

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

下载链接：https://github.com/apereo/cas/tags

开发文档：https://apereo.github.io/cas/5.2.x/index.html

官网：https://www.apereo.org/projects/cas

二、SSO
1、SSO简介
单点登录（ Single Sign-On , 简称 SSO ）是多个相关但独立的软件系统访问控制的一个属性。通过使用该属性，用户登录与单个ID和密码来访问所连接的一个或多个系统，而不使用不同的用户名或密码，或在某些配置中无缝登录在每个系统上，它是比较流行的服务于企业业务整合的一种解决方案。总结一句话，SSO 使得在多个应用系统中，用户只需要 **登录一次 **就可以访问所有相互信任的应用系统。

举个栗子：阿里巴巴旗下的淘宝网，你在浏览器里登录了，打开阿里云或者天猫就会发现可以不用在登录了，这里就是使用了SSO。

在SSO体系中，主要包括三部分：

User （多个）
Web 应用（多个）
SSO 认证中心（ 1 个）
而SSO的实现基本核心原则如下：

所有的登录都在 SSO 认证中心进行
SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户
SSO 认证中心和所有的 Web 应用建立一种信任关系， SSO 认证中心对用户身份正确性的判断会通过某种方法告之 Web 应用，而且判断结果必须被 Web 应用信任。
2、SSO原理
2.1 、登录
上面介绍我们知道，在SSO中有一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。那其他的系统如何访问受保护的资源？这里就是通过认证中心间接授权通过令牌来实现，当SSO验证了用户信息的正确性后，就会创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。

 

上面是一张SSO登录原理图，下面我们来分析一下具体的流程：

首先用户访问系统1受保护的资源，系统1发现未登陆，跳转至SSO认证中心，并将自己的参数传递过去
SSO认证中心发现用户未登录，将用户引导至登录页面
用户输入用户名和密码提交至SSO认证中心
SSO认证中心校验用户信息，创建用户与SSO认证中心之间的会话，称为全局会话，同时创建授权令牌
SSO认证中心带着令牌跳转会最初的请求地址（系统1）
系统1拿到令牌，去SSO认证中心校验令牌是否有效
SSO认证中心校验令牌，返回有效，注册系统1的地址
系统1使用该令牌创建与用户的会话，称为局部会话，返回给用户受保护资源
用户访问系统2受保护的资源
系统2发现用户未登录，跳转至SSO认证中心，并将自己的地址作为参数传递过去
SSO认证中心发现用户已登录，跳转回系统2的地址，并附上令牌
系统2拿到令牌，去SSO认证中心校验令牌是否有效
SSO认证中心校验令牌，返回有效，注册系统2地址
系统2使用该令牌创建与用户的局部会话，返回给用户受保护资源
用户登录成功之后，会与SSO认证中心及各个子系统建立会话，用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心，全局会话与局部会话有如下约束关系：

局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁
2.2 、注销
既然有登陆那么就自然有注销，单点登录也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁。原理图如下：

 

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

同样的我们也来分析一下具体的流程：

用户向系统1发起注销请求
系统1根据用户与系统1建立的会话id拿到令牌，向SSO认证中心发起注销请求
SSO认证中心校验令牌有效，销毁全局会话，同时取出所有用此令牌注册的系统地址
SSO认证中心向所有注册系统发起注销请求
各注册系统接收SSO认证中心的注销请求，销毁局部会话
SSO认证中心引导用户至登录页面
上面的关于SSO原理部分参考单点登录原理与简单实现，如果不太理解可以去看看原文，作者写得很详细。

三、CAS 的基本原理
1、结构体系
在上面的文章中，我们介绍过，在CAS的结构中主要分两部分，一部分是CAS Server，另一部分是CAS Client。

CAS Server：CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials)。

CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。

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

其中主要的关键概念：

TGT（Ticket Granting Ticket）是存储在TGCcookie中的代表用户的SSO会话。
该ST（Service Ticket），作为参数在GET方法的URL中，代表由CAS服务器授予访问CASified应用程序（包含CAS客户端的应用程序）具体用户的权限。
（1）、CAS基本协议模式
结合官方的流程图，我们可以知道，CAS中的单点登录流程：

 

我们可以发现这里的流程与上面SSO执行的基本是一致，只是CAS协议流程图中，更加清楚的指定了我们在访问过程当中的各种情况，在SSO中令牌也是我们在CAS中的ST(Service Ticket)。

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

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

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

（2）、CAS代理模式
CAS协议的最强大的功能之一就是CAS服务可以作为另一个CAS服务的代理的能力，传输用户身份。

同样的我们还是结合官方的流程图来分析：

 

加载代理应用

首先用户访问代理地址，权限没有认证，所以会把请求的URL以参数跳转到CAS认证中心，CAS认证中心发现没有SSO session，所以弹出登录页面，输入用户信息，提交到CAS认证中心进行信息的认证，如果信息正确，CAS认证中心就会创建一个SSO session——CASTGC cookie，这个CASTGC cookie包含了TGT，这个TGT作为一个用户session，它会分发一个ST返回给用户。用户拿到了ST后，访问带参数ST的代理地址，代理地址将ST发送给CAS认证中心并且带一个pgtUrl，这是请求一个PGT的回调URL。CAS认证中通过调用回调PGT URL将TGT和PGTIOU传递给代理地址，代理地址匹配存储PGTIOU和PGT并执行下一步，然后CAS返回一个PGTIOU给代理匹配刚刚存储是PGTIOU与PGT是否一致。后面就通过PGTIOU查找PGT，然后代理地址在建立相应的session cookie跳转到浏览器，用户再通过浏览器带cookie去访问代理地址。

通过代理访问应用

通过代理访问应用，在浏览器中通过携带相应的cookie去访问代理，然后验证session cookie的有效性，然后再代理地址通过PGT跳转到CAS认证中心，认证中心再通过代理地址访问应用，相同的步骤，应用发送ST给CAS认证中心，检验proxy ticket是否有效，如何有效返回给应用一个XML信息。在应用中查询代理URL是否可信赖，阻止代理用户非法的行为。然后应用再建立相应的session cookie跳转到代理地址，代理地址再带cookie去访问应用，并验证是否正确。如果正确，则应用响应代理地址的请求，代理地址再把请求发送给用户。

四、CAS术语概念
1、CAS 系统中的票据： TGC、TGT 、 ST 、 PGT 、 PGTIOU 、 PT 。
(1)、TGC（ticket-granting cookie）
授权的票据证明，由 CAS Server 通过 SSL 方式发送给终端用户，存放用户身份认证凭证的Cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证。

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

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

(4)、PGT（Proxy Granting Ticket）
Proxy Service的代理凭据。用户通过CAS成功登录某一Proxy Service后，CAS生成一个PGT对象，缓存在CAS本地，同时将PGT的值（一个UUID字符串）回传给Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以为Target Service（back-end service）做代理，为其申请PT。

(5)、PGTIOU（Proxy Granting Ticket I Owe You）
PGTIOU是CAS协议中定义的一种附加票据，它增强了传输、获取PGT的安全性。
PGT的传输与获取的过程：Proxy Service调用CAS的serviceValidate接口验证ST成功后，CAS首先会访问pgtUrl指向的Https URL，将生成的 PGT及PGTIOU传输给proxy service，proxy service会以PGTIOU为key，PGT为value，将其存储在Map中；然后CAS会生成验证ST成功的XML消息，返回给Proxy Service，XML消息中含有PGTIOU，proxy service收到XML消息后，会从中解析出PGTIOU的值，然后以其为key，在Map中找出PGT的值，赋值给代表用户信息的Assertion对象的pgtId，同时在Map中将其删除。

(6)、PT（Proxy Ticket）
PT是用户访问Target Service（back-end service）的票据。如果用户访问的是一个Web应用，则Web应用会要求浏览器提供ST，浏览器就会用Cookie去CAS获取一个ST，然后就可以访问这个Web应用了。如果用户访问的不是一个Web应用，而是一个C/S结构的应用，因为C/S结构的应用得不到Cookie，所以用户不能自己去CAS获取ST，而是通过访问proxy service的接口，凭借proxy service的PGT去获取一个PT，然后才能访问到此应用。

2、TGT、ST、PGT、PT之间关系
ST是TGT签发的。用户在CAS上认证成功后，CAS生成TGT，用TGT签发一个ST，ST的ticketGrantingTicket属性值是TGT对象，然后把ST的值redirect到客户应用。
PGT是ST签发的。用户凭借ST去访问Proxy service，Proxy service去CAS验证ST（同时传递PgtUrl参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT，PGT对象里的ticketGrantingTicket是签发ST的TGT对象。
PT是PGT签发的。Proxy service代理back-end service去CAS获取PT的时候，CAS根据传来的pgt参数，获取到PGT对象，然后调用其grantServiceTicket方法，生成一个PT对象。
3、其他概念
KDC(Key Distribution Center)----------密钥发放中心；

Authentication Service (AS) --------- 认证服务，索取Crendential ，发放 TGT；

Ticket-Granting Service (TGS) --------- 票据授权服务，索取TGT ，发放ST。

参考
单点登录原理与简单实现
https://apereo.github.io/cas/5.2.x/protocol/CAS-Protocol.html
单点登录(一)-----理论-----单点登录SSO的介绍和CAS+选型
https://en.wikipedia.org/wiki/Single_sign-on
SSO(Single Sign-on) in Action(上篇)
————————————————
版权声明：本文为CSDN博主「Anumbrella」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/anumbrella/article/details/80821486