CAS处理多个不同域名Web应用及桌面应用的单点登录（SSO）

使用CAS（Central Authentication Service）处理多个不同域名Web应用及桌面应用的单点登录（SSO）时，需解决跨域Cookie共享、非Web协议集成等核心挑战。以下是分场景的解决方案及关键技术要点：

浏览器默认禁止跨域共享Cookie，导致CAS的TGC（Ticket Granting Cookie）无法在不同域名间传递。

CAS中央认证流程：
- 首次登录应用A：用户访问appA.com → 重定向至CAS认证中心（cas.com） → 用户登录后，CAS生成TGT（Ticket Granting Ticket）并存储于cas.com域下的Cookie（TGC），同时签发ST（Service Ticket）返回给appA.com。
- 应用A验证ST：appA.com后台向cas.com验证ST有效性，获取用户身份，建立本地Session（局部会话）。
- 访问应用B：用户访问appB.com → 重定向至cas.com → 浏览器携带cas.com的TGC → CAS验证TGC有效后，直接签发新ST给appB.com → appB.com验证ST后建立局部会话，无需用户重复登录。
关键配置：
- CAS服务端：注册所有信任的Web应用域名（Service属性），例如：
  json
```
{ "serviceId": "^(https?://appA\.com|appB\.com).*", "id": 1001 }  // 允许appA.com和appB.com
```
  1
- 客户端：在Web应用中配置CAS Filter，指定cas.com的登录/验证地址（如edu.yale.its.tp.cas.client.filter.loginUrl）。

桌面应用无法直接使用浏览器Cookie机制，需通过协议桥接实现认证。

嵌入式浏览器认证：
- 桌面应用内嵌WebView组件加载CAS登录页。
- 用户登录后，CAS重定向至desktopapp://callback?st=XXX（自定义Scheme）。
- 桌面应用监听URL变化，从回调地址中提取ST，向后端兑换访问令牌。
后端API协作：
- 桌面应用调用后端API时携带访问令牌。
- 后端服务向CAS验证令牌有效性（如调用/proxyValidate接口）。
OAuth 2.0扩展：
- CAS可作为OAuth授权服务器，桌面应用使用授权码模式：
  1. 用户通过浏览器登录CAS，授权后返回授权码至本地回调服务。
  2. 桌面应用用授权码向CAS兑换Access Token。

跨域安全：
- HTTPS强制：所有CAS通信启用HTTPS，防止TGC/ST泄露。
- Cookie属性：设置TGC为Secure、HttpOnly，限定Domain为CAS主域（如.cas.com）。
- ST一次性：限制ST有效期（如5分钟）和单次使用。
桌面应用安全：
- PKCE扩展：防止授权码劫持（OAuth 2.0 PKCE）。
- 令牌存储加密：桌面应用本地安全存储访问令牌（如系统密钥库）。
统一登出（SLO）：
- 任一应用触发登出 → 通知CAS清除TGT → CAS主动回调所有已登录应用的登出接口（需提前注册logoutUrl）。

域名规划：
- Web应用使用共享父域名（如appA.example.com、appB.example.com），使CAS Cookie可通过.example.com共享。
- 完全独立域名需依赖CAS重定向流程传递ST。
证书与信任：
- CAS服务端配置SSL证书（如Keytool生成自签名证书，导入客户端JDK信任库）。
- 桌面应用需信任CAS的HTTPS证书链。
客户端适配：
- Web应用：使用CAS Client库（如Java的cas-client-core）。
- 桌面应用：实现OAuth 2.0客户端或自定义ST回调解析。

应用类型	认证流程	关键技术点
跨域Web应用	浏览器重定向 + CAS TGC共享 + ST验证	CAS Service注册、Cookie域控制
桌面应用	WebView登录/OAuth授权码 + 本地回调 + 令牌兑换	自定义URL Scheme、PKCE扩展、后端令牌验证
混合架构	Web应用走CAS协议，桌面应用走OAuth协议，CAS统一作为认证中心	CAS同时开启CAS和OAuth协议支持

💡 实施建议：
优先使用CAS 5.x+版本，原生支持OAuth/OIDC协议，简化桌面应用集成。
对于企业内网桌面应用，可结合系统级SSO（如Kerberos）减少用户交互，但需与CAS联邦集成。