CAS 单点登录详解

一、单点登录适合什么场景？

拿新浪举个单点登录的例子：

新浪微博与新浪博客是相互信任的应用系统:

当用户首次访问新浪微博时，新浪微博识别到用户未登录，将请求重定向到认证中心，认证中心也识别到用户未登录，则将请求重定向到登录页。

当用户已登录新浪微博访问新浪博客时，新浪博客识别到用户未登录，将请求重定向到认证中心，认证中心识别到用户已登录，返回用户的身份，此时用户无需登录即可使用新浪博客。

只要多个系统使用同一套单点登录框架那么它们将是相互信任的。

二、单点登录的三种实现方式

1、同域 SSO：没有设置独立的 SSO 服务器，因为业务后台服务器本身就足以承担 SSO 的职能。

2、同父域 SSO：和同域 SSO不同在于，服务器在返回 cookie 的时候，要把 cookie 的 domain 设置为其父域。

3、跨域SSO（CAS）：设置专门 SSO 服务器，当两个产品不同域时，cookie 无法共享，从而我们就需要搭建 SSO 服务器。

三、SSO

SSO 是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

一般 SSO 体系主要角色有三种：

• 1、 User （多个）
• 2、 Web 应用（多个）
• 3、 SSO 认证中心（ 1 个 ）

四、CAS

CAS 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（SSO的一种框架）。

CAS 包括两部分：

• CAS Server：负责完成对用户的认证工作 , 需要独立部署，CAS Server 会处理用户名/密码等凭证(Credentials) 。
• CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名/密码等 Credentials ）。CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

CAS 的几个重要知识点：

1）接口：

• /login：登录接口，用于登录到中心服务器。
• /logout：登出接口，用于从中心服务器登出。

2）票据：

• TGT (Ticket Grangting Ticket)：TGT 是 CAS 为用户签发的登录票据，拥有了 TGT，用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。
• TGC(Ticket Granting Cookie)：CAS Server 生成 TGT 放入自己的 Session 中，而 TGC 就是这个 Session 的唯一标识（SessionId），以 Cookie 形式放到浏览器端，是 CAS Server 用来明确用户身份的凭证。
• ST(Service Ticket)：ST 是 CAS 为用户签发的访问某一服务的票据。用户访问服务时，服务发现用户没有 ST，则要求用户去 CAS 获取 ST。
• PGT(Proxy Granting Ticket)：由 CAS Server 颁发给拥有 ST 凭证的服务，PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，获得 PT 的能力。
• PT(Proxy Ticket)：是应用程序代理用户身份对目标程序进行访问的凭证。

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。

参考：https://blog.csdn.net/u014723137/article/details/137358765