SSO原理 (CAS)

最新推荐文章于 2019-07-28 23:27:49 发布

IT382566697

最新推荐文章于 2019-07-28 23:27:49 发布

阅读量199

点赞数

分类专栏： JAVA cas原理文章标签： sso

本文链接：https://blog.csdn.net/it382566697/article/details/84489334

版权

JAVA 同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

cas原理

2 篇文章 0 订阅

订阅专栏

SSO原理（转至https://steven-wiki.readthedocs.org/en/latest/security/sso/）

CAS原理浅谈

本笔记参考自 SSO原理浅谈

简单的SSO体系结构:

User(多个)
Web应用(多个)
SSO认证中心(1个)

CAS的基本原理

CAS(Central Authentication Service)是Yale大学发起的一个开源项目 CAS是SSO的一种实现.

CAS的结构体系

CAS Server

CAS Server负责完成对用户的认证工作, 需要独立部署
CAS Client

CAS Client部署在客户端，原则上，CAS Client的部署意味着，当有对本地Web应用的受保护访问请求，并且需要对请求方进行身份认证，Web应用不再接受任何的用户名密码等 Credential, 而是重定向到CAS Server进行认证.

原始SSO实现

Web时代还处于初级阶段时，SSO是通过共享cookie来实现，由于cookie无法跨域，所以如果几个Web应用想做到SSO，要求他们的域名在同一个域，这样各个站点才能共享基于这一域名的cookie,这种方法不灵活而且有不少安全隐患, 已经被抛弃了.

CAS基础协议

上图是一个最基础的CAS协议，CAS Client以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，同时，CAS Client会分析HTTP请求中是否包请求Service Ticket(上图中的Ticket)，如果没有，则说明该用户是没有经过认证的，于是，CAS Client会重定向用户请求到CAS Server(Step 2). Step 3 是用户认证过程，如果用户提供了正确的 Credentials, CAS Server会产生一个随机的Service Ticket, 然后, 缓存该Ticket，并且重定向用户到CAS Client(附带刚才产生的Service Ticket), Service Ticket是不可以伪造的，最后，Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实，用 Ticket 查到 Username ，因为 Ticket 是 CAS Server 产生的，因此，所以 CAS Server 的判断是毋庸置疑的.

该协议完成了一个很简单的任务，就是 User(david.turing) 打开 IE ，直接访问 helloservice 应用，它被立即重定向到 CAS Server 进行认证， User 可能感觉到浏览器在 helloservcie 和 casserver 之间重定向，但 User 是看不到， CAS Client 和 CAS Server 相互间的 Service Ticket 核实(Validation)过程. 当CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份， CAS Client 才会对当前 Request 的用户进行服务.

Note

经过Step3之后， CAS Server将用户重定向到CAS Client, 可以将刚才产生的Service Ticket附加在URL中的，这样整个过程就可以不使用Cookie了. 当然了，这个地方使用cookie也是没有问题的，CAS不存在cookie跨域的问题，因为单点控制在CAS Server, CAS Server就只有一个.

CAS代理模式

CAS基础协议已经能够满足大多数的SSO应用，考虑一种更复杂的情况：用户访问hellservice, helloservice又依赖于 helloservice2来获取一些信息，这种情况下，假设helloservice也是需要对User进行身份验证的.

针对这种情况, CAS引入了一种Proxy认证机制，即CAS Client可以代理用户去访问其他的Web应用.

CAS安全性

CAS的安全性依赖SSL.

TGC/PGT安全性

对于一个CAS用户来说，最重要的就是保护它的TGC(Ticket Granting Cookie), 如果TGC不慎被CAS Server以外的实体获得， Hacker能够找到该TGC, 然后冒充CAS用户访问**所有资源**.

合理设置TGC超时时间, 默认是2个小时 .. note:: 由于有SSL保护，所以TGC(或者ST service ticket, PT proxy ticket)面临的风险主要并非传输窃取, 而是当用户离开电脑后其他人可以直接访问你已经授权的应用，所以设置一个TGC的有效期，可以减少被别人盗用你系统目录下的TGC cookie的风险.