CAS单点登录原理解析（转载）

1、基于Cookie的单点登录的回顾

基于Cookie的单点登录核心原理：

  将用户名密码加密之后存于Cookie中，之后访问网站时在过滤器（filter）中校验用户权限，如果没有权限则从Cookie中取出用户名密码进行登录，让用户从某种意义上觉得只登录了一次。

  该方式缺点就是多次传送用户名密码，增加被盗风险，以及不能跨域。同时www.qiandu.com与mail.qiandu.com同时拥有登录逻辑的代码，如果涉及到修改操作，则需要修改两处。

2、统一认证中心方案原理
在生活中我们也有类似的相关生活经验，例如你去食堂吃饭，食堂打饭的阿姨（www.qiandu.com）告诉你，不收现金。并且告诉你，你去门口找换票的（passport.com）换小票。于是你换完票之后，再去找食堂阿姨，食堂阿姨拿着你的票，问门口换票的，这个票是真的吗？换票的说，是真的，于是给你打饭了。
基于上述生活中的场景，我们将基于Cookie的单点登录改良以后的方案如下：

经过分析，Cookie单点登录认证太过于分散，每个网站都持有一份登陆认证代码。于是我们将认证统一化，形成一个独立的服务。当我们需要登录操作时，则重定向到统一认证中心http://passport.com。于是乎整个流程就如上图所示：
第一步：用户访问www.qiandu.com。过滤器判断用户是否登录，没有登录，则重定向（302）到网站http://passport.com。
第二步：重定向到passport.com，输入用户名密码。passport.com将用户登录的信息记录到服务器的session中。
第三步：passport.com给浏览器发送一个特殊的凭证，浏览器将凭证交给www.qiandu.com，www.qiandu.com则拿着浏览器交给他的凭证去passport.com验证凭证是否有效，从而判断用户是否登录成功。
第四步：登录成功，浏览器与网站之间进行正常的访问。

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

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

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

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

4、CAS的详细登录流程

上图是3个登录场景，分别为：第一次访问www.qiandu.com、第二次访问、以及登录状态下第一次访问mail.qiandu.com。

下面就详细说明上图中每个数字标号做了什么，以及相关的请求内容，响应内容。

整体流程见链接?
转载自
https://www.cnblogs.com/lihuidu/p/6495247.html