CAS 实现单点登录（SSO）原理

最新推荐文章于 2024-08-26 18:21:30 发布

一斤草莓吃光光

最新推荐文章于 2024-08-26 18:21:30 发布

阅读量1.3k

点赞数 1

分类专栏：新技术相关文章文章标签： cas 单点登录原理 ST TGC

新技术相关文章专栏收录该内容

3 篇文章 0 订阅

订阅专栏

原地址：https://blog.csdn.net/hejingyuan6/article/details/44277023
一、概念：
单点登录（Single Sign On）：简称为SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS（Central Authentication Service）：中央认证服务。CAS(Central Authentication Service)是一款不错的针对 Web应用的单点登录框架。
讲解CAS之前先来学习两个基本术语
二、术语解释：
1、TGC：Ticket-granting cookie，存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息。
2、TGT：ticket granting ticket，TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT。
3、ST：service ticket，CAS为用户签发的访问某一service的票据，ST是TGT签发的。
4、PGT：proxy granting ticket，代理模式下的TGT
5、PT：proxy ticket，代理模式下的ST
6、service：在cas系统中，接入的各个子系统叫服务。因为对普通用户来说，每一个接入到cas认证中心的子系统都提供特定的服务比如商城、bbs等，大家都听过软件即服务，平台即服务，这样理解service就通顺了
SaaS：Software-as-a-Service，软件即服务
PaaS：Platform as a Service，平台即服务
7、credentials，凭证，即待认证的用户的信息载体，如用户名+密码
8、Principal，当事人，即认证之后返回的已认证的当事人的信息载体，默认只返回用户ID即用户名。
9、Authentication表示一个完成的认证请求，当然，结果可能是凭证有效或无效，他有一个method可以获取
三、深入CAS
从结构上看，CAS包含两个部分：
CAS Server：CASServer 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 /密码等凭证 (Credentials) 。
CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。
CASClient 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
CAS最基本的协议过程：
在这里插入图片描述
CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护 Web应用的受保护资源，过滤从客户端过来的每一个 Web 请求
步骤详解：
（step 1）Web浏览器访问CAS Client，无session并且无票据(ST)，定向到CASServer
（step 2）又因为浏览器中并没有cookie，故服务端拿不到TGC，因此需要重新登录
（Step 3）是用户认证过程，如果用户提供了正确的CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，认证成功后，CAS生成cookie（叫TGC），写入浏览器，同时生成一个TGT对象，再根据TGT发放票据ST，并且重定向用户到CAS Client（附带刚才产生的ServiceTicket）， Service Ticket 是不可以伪造
（step4）注：ST前半部分为登录url，后半部分为我客户端要访问的页面地址，只有当登录成功才会直接转向客户端访问的页面
（Step 5）拿着ST去 CAS Server验证一下，验证成功返回用户信息（step6）
注：收到ST后，为什么还要验证呢？
因为CAS知道这个用户已经登录过了，但是对于这个项目来说，我并不知道这个用户已经登录过了，故需要验证
当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
1)如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；
2)如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
CAS 请求认证时序图如下：
在这里插入图片描述
１. CAS服务端登录时处理：
第一步：cas往浏览器增加cookie（TGC）
CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-grantingcookie”，用来表明用户已经成功地登录。
这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。用于以后其它应用客户端登录。
第二步：cas同时创建一个ticket(ST)重定向到原来的cas客户端。
认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。
２. CAS 客户端应用Ａ的处理
第一步：收到ticket后，向cas提交验证ticket。
第二步：ticket验证后创建session
以后登录此应用时，没有ticket，但IE。能提供session,从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用。
到此为止，CAS会记录用户已在应用Ａ已经登录。
３. 用户登录到应用Ｂ是如何处理
用户进入应用Ｂ时，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。然后，CAS同样给出新的ticket重定向应用Ｂ给cas验证（流程同应用Ａ验证方式），如果验证成功则应用Ｂ创建session记录CASReceipt信息到session中，以后凭此session登录应用Ｂ。
原理：１个cookie+Ｎ个session
CAS创建cookie在所有应用中登录时cas使用,各应用通过在IE创建各自的session来标识应用是否已经登录。
Cookie:在cas为各应用登录时使用，实现了只须一次录入用户密码
Session:各应用会创建自己的session表示是否登录
具体描述一下客户端消息流程
1.第一次访问http://localhost:8080/a,
CLIENT：没票据且SESSION中没有消息所以跳转至CAS
CAS：拿不到TGC故要求用户登录
2. 认证成功后回跳
CAS：通过TGT生成ST发给客户端，客户端保存TGC，并重定向到http://localhost:8080/a
CLIENT：带有票据(ST)所以不跳转只是后台发给CAS验证票据（浏览器中无法看到这一过程）
3.第一次访问http://localhost:8080/b
CLIENT：没票据且SESSION中没有消息所以跳转至CAS
CAS：从客户端取出TGC，如果TGC有效则给用户ST并后台验证ST，从而SSO。【如果失效重登录或注销时，怎么通知其它系统更新SESSION信息呢？？TicketGrantingTicketImpl类grantServiceTicket方法里this.services.put(id,service);可见CAS端已经记录了当前登录的子系统】
单点退出：
4.再次访问http://localhost:8080/a
CLIENT：没票据但是SESSION中有消息故不跳转也不用发CAS验证票据，允许用户访问