认识
一、认识
在 Web 应用中实现跨不同顶级域的 SSO（单点登录） 方案，通常会面临浏览器同源策略（Same-Origin Policy）的限制。在同顶级域下，通过设置 Cookie 的 domain 属性可以轻松实现跨子域的认证。然而，在不同顶级域（例如 example.com 和 example.org）下，由于浏览器的安全策略，不同的顶级域不能直接共享 Cookie, 直接通过 Cookie 来实现跨域认证变得困难。
CAS（Central Authentication Service） 是一个广泛使用的 单点登录（SSO） 协议，它通过集中式的身份认证服务，让多个应用程序或服务共享一个认证过程，减少用户登录的次数。CAS 是由 Yale University 在 2000 年左右开发的，它的目标是简化跨应用的身份验证流程，提升用户体验，并减少密码泄露的风险。
CAS 的工作原理类似于 OAuth 或 SAML，但是 CAS 协议比它们更加简洁和轻量，且通常用于内网或基于 Web 的应用中，具有广泛的企业级使用场景。
在现代企业架构中，CAS 的实现使得不同的应用可以通过集中式的身份验证平台管理用户会话，从而实现跨应用和跨域的无缝登录体验。
二、工作流
CAS SSO 架构如下:
-
身份提供者 (
IdPIdentity Provider): 比如idp.example.com，是一个用于验证用户身份并提供认证信息的系统。它通常负责维护用户的认证信息（如用户名、密码、认证方式等），并生成有关用户的身份声明（Assertion）。IdP生成SAML断言，用于证明用户身份的消息。它通常以XML格式传输，并包含用户身份信息、认证方法、授权信息等内容。 -
服务提供者 (
SPService Provider):app.example.com、portal.example.org、ccc.example.xyz等多个Web应用, 是使用用户身份信息的应用程序或系统。当用户尝试访问一个SP时，它会将请求重定向到IdP进行认证。
CAS SSO 流程如下:
1. 用户登录认证: 用户在浏览器中访问某个 服务提供者（SP），例如 app.example.com。SP 发现用户没有有效的会话或认证信息（如会话 cookie、token 等），于是将用户重定向到 身份提供者（CAS Server） 进行认证。该重定向请求会携带一些必要的参数，例如: service, 指向原本的应用（服务提供者）的 URL，用于认证成功后的回调地址。用户被重定向到 CAS Server 的登录页面。在此页面上，用户输入用户名和密码进行身份验证。CAS Server 验证凭证的正确性。如果凭证验证成功，CAS Server 会生成一个 ticket（通常是一个短时间有效的票据，称为 TGT，Ticket Granting Ticket）并将其存储在 CAS Server 的会话管理中。如果验证失败，CAS 会提示错误信息并要求用户重新登录。在验证成功后，CAS Server 会生成一个包含认证信息的 Service Ticket（ST）。ST 是由 CAS Server 签发的一个短期有效的唯一标识符。然后，CAS Server 会将该 Service Ticket 附加到重定向 URL 中，返回给 SP。当 SP 收到带有 Service Ticket 的重定向请求时，它会向 CAS Server 发起一个验证请求，验证 Service Ticket 是否有效。CAS Server 接收到验证请求后，会检查票据是否有效，是否匹配之前颁发给该用户的 Service Ticket。如果有效，CAS 会返回一个包含用户信息的 XML 响应，其中包含 用户名 和其它相关信息（如角色、权限等）。SP 解析来自 CAS Server 的响应，如果验证成功，SP 会使用返回的用户信息建立用户的会话，并将用户重定向到服务的目标页面。在此过程中，SP 可以创建 session，或者通过 cookie 存储用户信息，从而实现用户的认证会话。
-
Ticket Granting Ticket（TGT）：TGT是一个长期有效的身份票据，它存储在CAS Server上，每次用户通过SP进行认证时，都会首先验证该票据是否存在以及是否有效。TGT是实现单点登录的基础。 -
Service Ticket（ST）：ST是一个短期有效的票据，每次用户访问某个SP时，SP都会通过CAS Server颁发一个ST，用于验证用户的身份。ST的有效期较短，一般为几分钟，使用后会失效。 -
Session Management：CAS Server在维护用户会话时，通常会通过Cookie或其他机制来标识当前用户的身份。每次SP向CAS Server请求认证时，都会通过service参数来传递用户的原始请求URL。CAS Server根据该URL确定是否允许用户访问受保护的资源。 -
Service Validation：每当用户尝试访问受保护资源时，SP会验证用户的Service Ticket是否有效。CAS服务器会向SP提供关于该Service Ticket的信息，以确认用户身份。
2. 用户后续请求验证: 此时用户已经通过 SP 完成了认证，并获得了访问 SP 中资源的权限。此后的请求中，浏览器会自动携带 SP 设置的会话信息（如 cookie），以便 SP 验证用户身份。
3. 跨服务提供者的认证:
CAS Server 负责全局会话的管理，保持用户的登录状态。各个 SP 负责局部会话的管理，通过与 CAS Server 的交互保持一致。
用户在 SP1 和 SP2 之间的认证是通过 IdP 中的全局会话来完成的。SP1 和 SP2 都依赖于 IdP 维护的用户认证信息、全局会话，但它们分别维护各自的局部会话。这种跨域、跨应用的认证机制即实现了 SSO（Single Sign-On），用户只需要在第一次登录时输入用户名和密码，后续的访问请求都会自动完成认证，无需再次登录。
用户登录成功之后，会与 IdP（Identity Provider，身份提供者） 及各个 SP（Service Provider，服务提供者） 建立会话，用户与 IdP（Identity Provider，身份提供者） 建立的会话称为全局会话，用户与各个 SP（Service Provider，服务提供者） 建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过 IdP（Identity Provider，身份提供者），全局会话与局部会话有如下约束关系
-
局部会话存在，全局会话一定存在
-
全局会话存在，局部会话不一定存在
-
全局会话销毁，局部会话必须销毁