目录
- 单点登录简介
- SSO&CAS是什么
- 单点登录适合什么场景
- 单点登录的三种实现方式
- CAS的几个重要知识点
- CAS的实现过程
单点登录简介
单点登录(SingleSignOn，SSO)，就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗，辅助了用户管理，是目前比较流行的。
A.传统登录流程图：
B.单点登录流程图：
SSO&CAS是什么
SSO
SSO是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要 登录一次 就可以访问所有相互信任的应用系统。
CAS
CAS 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（SSO的一种框架）
CAS 包括两部分：CAS Server 和 CAS Client
- CAS Server：负责完成对用户的认证工作 , 需要独立部署。
- CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。
阶段汇总集合：一年内容，200期Java面试题阶段汇总
单点登录适合什么场景
拿新浪举个单点登录的例子
新浪微博与新浪博客是相互信任的应用系统:
- 当用户首次访问新浪微博时，新浪微博识别到用户未登录，将请求重定向到认证中心，认证中心也识别到用户未登录，则将请求重定向到登录页。
- 当用户已登录新浪微博访问新浪博客时，新浪博客识别到用户未登录，将请求重定向到认证中心，认证中心识别到用户已登录，返回用户的身份，此时用户无需登录即可使用新浪博客。
- 只要多个系统使用同一套单点登录框架那么它们将是相互信任的。
单点登录的三种实现方式
1.同域SSO
没有设置独立的 SSO 服务器，因为业务后台服务器本身就足以承担 SSO 的职能。
2.同父域SSO
和同域SSO不同在于，服务器在返回 cookie 的时候，要把cookie 的 domain 设置为其父域。
3.跨域SSO（CAS）
设置专门SSO服务器，当两个产品不同域时，cookie无法共享，从而我们就需要搭建SSO服务器。
CAS的几个重要知识点
接口：
/login：登录接口，用于登录到中心服务器。
/logout：登出接口，用于从中心服务器登出。
票据
1. TGT (Ticket Grangting Ticket) :
TGT 是 CAS 为用户签发的登录票据，拥有了 TGT，用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。
2.TGC(Ticket Granting Cookie) :
CAS Server 生成TGT放入自己的 Session 中，而 TGC 就是这个 Session 的唯一标识（SessionId），以 Cookie 形式放到浏览器端。
3.ST(Service Ticket) :
ST 是 CAS 为用户签发的访问某一 service 的票据。用户访问 service 时，service 发现用户没有 ST，则要求用户去 CAS 获取 ST。
CAS的实现过程
跨域SSO（CAS）实现过程
- 用户访问产品 a，域名是 www.a.cn。
- 由于用户没有携带在 a 服务器上登录的 a cookie，所以 a 服务器重定向到SSO 服务器的地址。
- 由于用户没有携带在 SSO 服务器上登录的 TGC，所以 SSO 服务器判断用户未登录，给用户显示统一登录界面。
- 登录成功后，SSO 服务器构建用户在 SSO 登录的 TGT，同时返回一个 http 重定向（包含 sso 服务器派发的 ST ）。
- 重定向的 http response 中包含写 cookie。这个 cookie 代表用户在 SSO 中的登录状态，它的值是 TGC。
- 浏览器重定向到产品 a。此时重定向的 url 中携带着 SSO 服务器生成的 ST。根据 ST，a 服务器向 SSO 服务器发送请求，SSO 服务器验证票据的有效性。验证成功后，a 服务器知道用户已经在 sso 登录了，于是 a 服务器构建用户登录 session。
- 用户访问产品 b，域名是 www.b.cn。
- 由于用户没有携带在 b 服务器上登录的 b cookie，所以 b 服务器重定向到SSO 服务器，去询问用户在 SSO 中的登录状态。
- 浏览器重定向到 SSO服务器。由于已经向浏览器写入了携带 TGC 的cookie，所以此时 SSO 服务器可以拿到，根据 TGC 去查找 TGT，如果找到，就判断用户已经在 sso 登录过了。
- SSO 服务器返回一个重定向，重定向携带 ST。
- 浏览器带 ST 重定向到 b 服务器。
- b 服务器根据票据向 SSO 服务器发送请求，票据验证通过后，b 服务器知道用户已经在 sso 登录了，于是生成 b session，向浏览器写入 b cookie。
