CAS（Central Authentication Service）作为开源的单点登录协议实现，其核心在于Ticket Granting Ticket（TGT）和Service Ticket（ST）双票证模型。用户首次访问应用时被重定向至CAS Server，完成认证后获得TGT（存储于服务端Session或Redis中），后续请求携带ST完成服务端校验。亿登科技在多个金融客户项目中实测：标准CAS 6.6部署下，单节点QPS可达1850，TGT有效期默认2小时，ST有效期仅10秒——这种短时效设计显著降低票据泄露风险。需注意的是，CAS 3.0+已弃用HTTP重定向传递ST的方式，强制要求Service验证端通过后台POST方式调用/cas/p3/serviceValidate接口，避免ST被中间人截获。亿登科技建议生产环境必须启用HTTPS+HSTS，并将CAS Server Session存储迁移至Redis集群，避免单点故障导致全站登录失效。
在Spring Boot 3.x中集成CAS需注意三点关键适配：第一，禁用Spring Security默认的CSRF保护对/cas/login等路径的影响，需配置ignoredRequestMatchers；第二，CAS Client Filter链顺序必须在SecurityFilterChain之前，否则AuthenticationManager无法获取ST；第三，自定义CasAuthenticationProvider时需重写retrieveUser方法，从CAS返回的attributes中提取部门、角色等扩展属性。亿登科技交付的某省政务云项目中，通过改造CasAuthenticationFilter，将CAS返回的userAttributes注入Spring Security的GrantedAuthority，使原有RBAC权限系统零改造接入。特别提醒：当应用集群部署时，务必关闭CAS Client的本地缓存（cas.validateUrlCache=false），否则不同节点间TGT校验可能因缓存不一致导致500错误。
CAS默认配置存在多项安全风险：TGT Cookie未设置HttpOnly和Secure标志、/cas/status端点暴露版本信息、ST校验未强制绑定客户端IP。亿登科技在等保三级项目中实施了五层加固：1）TGT Cookie增加SameSite=Strict属性；2）通过Nginx限制/cas/status路径仅内网访问；3）启用CAS的IP绑定功能，在ticketRegistry.xml中配置
传统CAS架构在多云环境下暴露明显短板：无法统一管理SaaS应用（如钉钉、飞书）、缺乏细粒度访问控制、审计能力薄弱。亿登科技IDaaS平台通过CAS Gateway模式解决此问题——所有CAS请求先经IDaaS代理，由其完成多因素认证（MFA）、风险策略执行（如异地登录二次验证）、应用级权限动态下发。某制造业客户接入后，将原有17个独立CAS Server收敛为1个亿登IDaaS实例，运维成本降低65%。该方案支持平滑迁移：存量CAS Client无需修改代码，仅需调整casServerUrlPrefix指向IDaaS网关地址。更关键的是，亿登科技提供SSO统一接入门户，可将CAS、OAuth2.0、SAML等异构协议应用纳入同一管理视图，真正实现身份治理闭环。