基于Cookie的单点登录的回顾

未命名文件.png

基于Cookie的单点登录核心原理：
将用户名密码加密之后存于Cookie中，之后访问网站时在过滤器（filter）中校验用户权限，
如果没有权限则从Cookie中取出用户名密码进行登录，让用户从某种意义上觉得只登录了一次。
该方式缺点就是多次传送用户名密码，增加被盗风险，以及不能跨域。

同时www.tuya.com与mail.tuya.com同时拥有登录逻辑的代码，如果涉及到修改操作，则需要修改两处。

统一认证中心方案原理

在生活中我们也有类似的相关生活经验，例如你去食堂吃饭，食堂打饭的阿姨（www.tuya.com）告诉你，不收现金。

并且告诉你，你去门口找换票的（passport.com）换小票。于是你换完票之后，再去找食堂阿姨，食堂阿姨拿着你的票，问门口换票的，

这个票是真的吗？换票的说，是真的，于是给你打饭了。
基于上述生活中的场景，我们将基于Cookie的单点登录改良以后的方案如下：

未命名文件 (2).png

经过分析，Cookie单点登录认证太过于分散，每个网站都持有一份登陆认证代码。于是我们将认证统一化，形成一个独立的服务。

当我们需要登录操作时，则重定向到统一认证中心http://passport.com。于是乎整个流程就如上图所示：

第一步：用户访问www.tuya.com。过滤器判断用户是否登录，没有登录，则重定向（302）到网站http://passport.com。

第二步：重定向到passport.com，输入用户名密码。passport.com将用户登录的信息记录到服务器的session中。

第三步：passport.com给浏览器发送一个特殊的凭证，浏览器将凭证交给www.tuya.com，www.tuya.com则拿着浏览器交给他的凭证去passport.com验证凭证是否有效，从而判断用户是否登录成功。

第四步：登录成功，浏览器与网站之间进行正常的访问。

Yelu大学研发的CAS(Central Authentication Server)

下面就以耶鲁大学研发的CAS为分析依据，分析其工作原理。首先看一下最上层的项目部署图：

部署项目时需要部署一个独立的认证中心（cas.tuya.com），以及其他N个用户自己的web服务。

认证中心：也就是cas.tuya.com，即cas-server。用来提供认证服务，由CAS框架提供，用户只需要根据业务实现认证的逻辑即可。

用户web项目：只需要在web.xml中配置几个过滤器，用来保护资源，过滤器也是CAS框架提供了，即cas-client，基本不需要改动可以直接使用。

CAS的详细登录流程

cas.png

蓝色实线为第一次登陆www.tuya.com

蓝色虚线为第二次登录www.tuya.com

紫色实线为第一次登录mail.tuya.com

其中需要了解标号5的请求，以及标号6的响应了。当cas.tuya.com即csa-server认证通过之后，会返回给浏览器302，重定向的地址就是Referer中的service参数对应的值。后边并通过get的方式挟带了一个ticket令牌，这个ticket就是ST（数字6处）。同时会在Cookie中设置一个CASTGC，该cookie是网站cas.tuya.com的cookie，只有访问这个网站才会携带这个cookie过去。
Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问cas.tuya.com时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。
TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字6处的ticket值。