SSO及CAS浅谈

最新推荐文章于 2025-02-19 00:00:00 发布

玉宇惟思

最新推荐文章于 2025-02-19 00:00:00 发布

阅读量1.7w

点赞数 8

分类专栏： SSO

本文链接：https://blog.csdn.net/u013406199/article/details/80258608

版权

SSO 专栏收录该内容

1 篇文章

订阅专栏

单点登录SSO（Single Sign On）。抛开前人成果，细细想来无非存储信任，验证信任，作用范围和安全性。粗略想想采用cookie或者单独的管理系统应该都能实现，貌似也不是很遥远的东西，但是真正做好还有很远的路。

一、SSO的两种架构

集中验证：各系统登录交由专门的信任验证服务器完成登录动作，统一了用户账户密码，但是一旦验证服务器宕机SSO功能将全部丧失；
多点验证：登录动作由各个系统完成，任何一台服务器宕机都不会影响其他系统，容错性好，各系统账户密码难以统一，用户体验差，技术上存在跨域问题；

二、SSO三种实现技术

代理登录（agent）：用于无法改造的旧系统；
令牌环（token）：通过Cookie共享令牌环的方式传递当前用户信息，实现SSO，存在跨域问题；
身份票据（ticket）：除了增加一台信任验证服务器，完全满足了存储信任，验证信任，作用范围和安全性的问题，也是适用最广的webSSO实现方式（接下来的CAS会具体讲解）

三、三种实现技术比较

比较项	代理登录	令牌环	身份票据
需求实现程度	无法实现同时切换用户与会话同时过期	全部	全部
对原系统改造	无	小量改造	小量改造
安全性	低	高	高
稳定性	偏低	好	好
性能开销	登录瞬间压力大一点	非常小	较小
适用范围	同域，对用户密码不一致的系统，需在登录服务器的用户凭证库保存用户密码映射	同域，对不同登录名需增加对用户凭证库的访问	所有可改造的系统，对不同登录名需在登录服务器的用户凭证库保存用户映射
独立验证服务器	需要	不需要	需要
登录模式支持	集中验证模式	集中验证模式/多点验证模式	集中验证模式

四、CAS

CAS框架：CAS（Central Authentication Service）是基于Kerberos票据方式实现SSO单点登录的框架。
经典图如下:
本文以下将用户操作的电脑称之为浏览器，CAS Client称之为系统X, CAS Server称之为认证中心
首次登陆详解

1）浏览器首次访问系统A，CASFilter截获请求，A获取不到JSessionID发现未登录，系统A将浏览器重定向到认证中心；

2）认证中心获取全局票据，未获取到，认定用户未登录给用户跳转到登录页进行登录。认证成功之后给浏览器生成一个全局票据（一般存放在cookie中称之为TGC--Ticket Granting Cookie，出于安全考虑TGC经过加密并且有时效性，关闭浏览器会自动过期），然后重定向到系统A并且附上临时票据（Service Ticket由认证中心随机生成并发放给用户的身份标志是一种一次性信任凭证）；

3）系统A的CASFilter截获请求，获取临时票据，获取到之后将临时票据传给认证中心确认（票据由认证中心生成，几乎不可伪造，标志用户身份）。认证中心通过认证之后将用户信息返回给系统A，系统A将浏览器请求授权资源返回；

4.已登录状态访问系统B详解

1）浏览器访问系统B，CASFilter截获请求，系统B获取JSessionID，未获取到，重定向至认证中心；

2）认证中心获取全局票据，获取到之后认定用户已经登录，认证中心发放系统B的临时票据，并重定向至系统B；

3）系统B获取临时票据，获取到之后将临时票据传给认证中心确认，认证中心通过认证之后将用户信息返回给系统B，系统B将浏览器请求资源返回；

5.登出

用户执行登出操作，当前系统会将登出请求重定向到认证中心（CAS Server），认证中心在收到登出请求后获取TGC清除对应session，同时通知所有通过此TGC对应的TGT直接或者间接签发授权的系统（CAS Client）消除session。

6.代理模式

当浏览器访问系统A，而系统A依赖于系统B的资源，如果按照之前的模式，那么必然要在各个系统和认证中心之间不断的重定向，导致用户体验不好，又或者是一个C/S结构无法获取cookie。为此CAS提供了Proxy认证机制，即CAS Client代替浏览器访问其他系统。

代理模式在系统A访问认证中心的时候会携带PGURL，认证中心会通过PGURL给系统A一个PG（Proxy Ticket）

7.安全性

对于CAS而言没有比保护它的TGC更加重要的事情了。一旦TGC被Hacker获取，Hacker便能冒充用户访问所有授权资源。CAS的传输安全性完全依赖于SSL，好在要截取这样的TGC难度非常大。

Service Ticket有几个特点，1.ST只能使用一次，即无论ST是否通过验证，认证中心都会将ST从缓存中清除；2.ST有时效性，不论ST是否去验证，在一段时间内都会失效；3.ST生成是随机的，这使伪造几乎不可能完成；ST的这些特点保证了ST本身的安全性，而ST使得密码不必在各系统之间传输又保证了密码的安全性。

TIPs：

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 ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
TGC （Ticket-granting cookie）
存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输Https），是CAS Server用来明确用户身份的凭证。
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。
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中将其删除。
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，然后才能访问到此应用。