cas配置怎么做？手把手教程详解

CAS配置核心结论

CAS（Central Authentication Service）配置的本质，是通过统一认证中心实现多应用系统的单点登录与集中鉴权，一次登录，全网通行；一处注销，处处失效，其配置成功与否的判断标准，不在于服务端能否启动，而在于认证票据在客户端、服务端、应用端三端链路中能否安全、高效地流转，一套生产级CAS配置方案，必须同时解决协议对接、会话安全、性能衰减三大核心问题。

CAS基本组件与协议选型

CAS体系由三部分组成：CAS Server（统一认证中心）、CAS Client（受保护应用）、TGT/ST票据，配置前首先需要明确协议版本。

CAS 2.0协议：支持代理认证（Proxy），适用于多级应用嵌套场景，但XML报文解析效率偏低。
CAS 3.0协议：引入REST API与JSON支持，适合前后端分离架构，推荐使用。
OAuth2/OIDC扩展：若涉及第三方登录或移动端场景，需要在CAS之上叠加OIDC（OpenID Connect）协议，通过配置pac4j组件实现。

票据配置的核心参数：

tgt.timeToKillInSeconds：TGT（Ticket Granting Ticket）有效期，建议生产环境设置为7200秒，并启用滑动过期机制。
st.timeToKillInSeconds：ST（Service Ticket）有效期，通常设置为10秒，时间过长易被重放攻击。
ticket.registry：推荐使用Redis TicketRegistry，替代默认内存模式，解决多节点会话共享问题。

安全配置最佳实践

强制HTTPS与证书链完整

CAS生产环境必须强制HTTPS,配置cas.server.name时，务必使用https://前缀，且证书链必须由受信任的CA签发，自签名证书在测试环境可以绕过，但在生产环境会导致所有CAS Client的SSL握手失败，在Nginx层配置TLS终止时，需额外注意：反向代理必须透传

X-Forwarded-Proto和Host头，否则CAS Server会认为所有请求都是HTTP，进而拒绝下发ServiceTicket。

经验案例（酷番云）：某电商客户在酷番云高防CDN后接入CAS服务，出现部分用户登录成功但回调失败的问题，排查发现是CDN节点改写X-Forwarded-Proto导致CAS Server误判协议，最终通过酷番云负载均衡器的原始协议透传配置，强制后端读取真实的X-Forwarded-Proto头，问题彻底解决，云端部署CAS时，务必确认云负载均衡与网关层不篡改协议头。

Service票据校验与防止开放重定向

CAS Clientservice参数是合法应用标识，生产配置必须启用Service Registry白名单机制：

在cas.service-registry.json中明确允许访问的Service URL列表，精确到协议、域名、端口、路径。
禁止使用正则表达式通配整个域名,防止攻击者构造恶意回调地址。
开启cas.ticket.st.onlyTrackMostRecentSession=true，同一TGT只允许最新ST有效，防御会话固定攻击。

加密与密钥管理

AES加密：CAS默认使用AES-128加密TGT，生产环境需配置自定义密钥，密钥强度建议AES-256，长度至少32字节。
签名算法：配置cas.authn.attributeRepository时，若通过JWT传递用户属性，签名算法必须使用RS256而非HS256，避免对称密钥泄露导致的伪造风险。
密钥轮换：在酷番云密钥管理服务（KMS）中托管CAS的加密密钥，执行每90天自动轮换策略，降低密钥长期暴露带来的数据泄露风险。

性能优化与高可用配置

会话存储水平扩展

默认的InMemoryTicketRegistry在重启后票据全部丢失，且无法横向扩展，生产配置应使用Redis分布式会话存储

：

cas:
  ticket:
    registry:
      redis:
        host: redis-cluster.example.com
        port: 6379
        useSsl: true
        pool:
          max-total: 200

在此配置下,所有CAS Server节点共享票据状态，实现无状态水平扩展。

应用端Session生命周期缩短

CAS Client侧必须配置较短的应用Session超时，与TGT的滑动过期机制协同工作，若应用Session保持8小时不动，而CAS TGT已过期，用户尝试访问应用时会出现二次认证，推荐配置：

应用Session超时：30分钟
CAS TGT滑动过期：2小时
强制在application.yml中开启cas.client.renew=false，避免每次请求都到Server端重新校验，降低认证中心压力。

大规模并发下的降级策略

当并发登录峰值超过认证中心承受能力时,服务降级优于认证失败，建议在CAS Server前增加酷番云弹性伸缩组策略：当CPU使用率超过70%持续5分钟，自动扩容CAS节点，扩容过程无需人工干预，同时在应用层面，保持已登录用户的Session不依赖CAS Server的实时状态，仅在Session过期或主动登出时才回调CAS，避免认证中心故障导致全站用户被强制下线。

独立见解与优化建议

这里给出一个极易被忽略的关键点：CAS配置不能止步于“能登录”，必须跨过统一登出这一隐形门槛，多数团队配置单点登录时只关注认证流程，忽视了SLO（Single Log Out）的异步通知机制，CAS Server执行登出后，需要向所有已登录的Service URL发送logoutRequest，生产环境中，这个回调请求超时时间要设置为300ms以上，并使用MQ异步发送，否则登出操作会阻塞用户响应。

另一个专业性见解：Cookie的HttpOnly和SameSite属性，是很多CAS配置方案中的盲区，CAS依赖Cookie存储TGT，如果Cookie未设置

HttpOnly，XSS攻击可直接窃取会话；若未设置SameSite=None; Secure，在跨域SSO场景下浏览器会拦截Cookie携带，导致登录态丢失，配置代码举例如下：

server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.same-site=strict

cas配置怎么做？手把手教程详解

CAS配置核心结论

CAS基本组件与协议选型