单点登录Cas如何保证客户端的安全性

同花顺

在一篇博客下边，我看到了这样一句话（如下图）：

这个使用redis就能实现吧，把用户的信息放在redis里面，当用户访问其他系统时直接从redis里面获取是否有该用户信息，有则放行，没有则跳转到登录页面。

随后我就毫不留情的开喷，你咋不说放到随便一个tomcat中也可以实现呢，确实也可以啊。只要是个服务器都能用于存放用户信息。
Cas解决的是存放用户信息的问题吗，还真是。（尬.jpg）

Cas占据了SSO领域的半壁江山。洋洋洒洒几W行代码绝对不是一个存储用户信息的服务器容器可以比拟的。

一个Cas下有很多个客户端，一旦用户信息被暴露，那么所有的客户端权限全部开放，就是一个很危险的事情。

Cas对客户端与服务端交互时的信息安全花了很大的功夫，设计出了一套ticket机制，有以下几种票据：
TGC 、 ST 、 TGT、PGT 、 PGTIOU 、 PT 、AS、TGS、KDC。
一看就很安全。

安全这方面，不可以较真，因为防不胜防。阿里云还能被攻克呢，所以说酒精是你道高一尺，还是我魔高一丈。
我们正常的开发，能防住普通的小毛贼就可以了。

已经有TGC了，为什么还需要ST

这是一个网友的提问。

我告诉你，不止有ST，还有PGT 、 PGTIOU 、 PT 、AS、TGS、KDC。

然后，你再接着问。

为什么还要有PT啊，有TGC和ST还不行吗？

为什么还要有TGS啊，有TGC和ST还不行吗？

所以说，没有为什么。

网上有这样两种解释：

第二种字多，所以第二种有理。

Cas如何保证客户端的安全性

我们正常的项目，普通的登录逻辑，使用的就是cookie与session组合。按理说，Cas项目使用一个cookie确实也足够了，但是Cas增加了Ticket的概念。

原因如下：

1、TGC与ST组合是一种双重保护，毕竟是单点登录一整个大家庭，很多个客户端，安全上必须重视。

TGC是一直存在客户端的，可以通过JS脚本来获取。

但是ST没有存在客户端，也没有存在服务端，你没有办法截取，除非你已经深入服务器内部，了解各个请求跳转环节，那你也没必要伪造ST了。

Cas对ST做了非常大的限制，它的默认生存时间为10秒，可以调的更低一点，因为请求重定向转发速度非常快，3s都绰绰有余。

2、ST规则：ST-1-7I7963LWBGk1jcUCfbls-xiaolaoben

有没有见过同样的ST，它是一个不规则的字符串，只能被一个客户端使用一次，使用过后就失效，时间到期也会失效。

TGT生成的ST，他们两个是父子关系，由TGT校验ST是不是亲生的。

TGT的默认生存时间为两个小时，不同的TGT生成的ST的规则不同。
就算你摸清了这个ST的规则，过了一会换了TGT，你伪造的ST，新的TGT不认识，校验不通过。

3、Map结构：<TGC，TGT>，<ST，TGT>。
访问cas-server时，判断一下cas-server中是否存在名为CONST_CAS_ASSERTION与TGC匹配的session，如果存在进行下一个过滤器。

校验时，TGT判断一下该ST是不是亲生的。Cas的登录逻辑就是TGC与ST配合，二者缺一不可。

Cookie的安全性

非法用户使用cookie
1、盗取cookie里你的用户信息。
2、模拟你的cookie，进入你的系统，拥有你的全部权限。

保护cookie的有效措施
1、cookie有效期设置不要太长。
2、设置HttpOnly属性为true，防止js脚本读取cookie信息，有效的防止XSS攻击。
3、加密Cookie，key与value采用自定义规则。
4、使用HTTPS加密协议，SSL协议传输，稳得一批。

Cas单点登录推荐你使用HTTPS协议，就是为了安全。

·······················································································
全部都是我瞎扯的，以上。