CAS 6.X.X版本SSO失效求助：Spring Boot多应用登录异常

问题现象 #

我有三个Spring Boot应用，通过对接Azure租户的CAS Server完成认证。原本期望用户登录任意一个应用后，访问另外两个应用无需再次登录，但升级CAS从5.3.16到6.2.8版本后，出现了跨应用访问时被重定向到登录页面的问题，旧版本下该功能正常。

CAS服务配置示例 #

服务通过JSON文件加载到CAS，三个应用的配置结构一致，以下是其中一个示例（not-1003.json）：

{
  "@class": "org.apereo.cas.services.RegexRegisteredService",
  "serviceId": "https://${ENV_EGATE_HOST}/not/.*",
  "name": "Notifications",
  "description": "eGate Notifications application",
  "id": 1003,
  "matchingStrategy": {
    "@class": "org.apereo.cas.services.FullRegexRegisteredServiceMatchingStrategy"
  },
  "logoutType": "FRONT_CHANNEL",
  "logoutUrl": "https://${ENV_EGATE_HOST}/not/j_spring_cas_security_logout",
  "evaluationOrder": 10000003,
  "attributeReleasePolicy": {
    "@class": "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
  }
}

CAS核心配置（cas.properties） #

cas.server.name=https://${ENV_EGATE_HOST}
cas.server.prefix=${cas.server.name}/cas
server.port=8443

cas.service-registry.init-from-json=false
cas.service-registry.json.location=file:${ENV_CAS_CONFIGPATH}/services

cas.authn.pac4j.oidc[0].generic.type=AZURE
cas.authn.pac4j.oidc[0].generic.discoveryUri=https://login.microsoftonline.com/${ENV_AZURE_TENANTID}/v2.0/.well-known/openid-configuration
cas.authn.pac4j.oidc[0].generic.logoutUrl=https://login.microsoftonline.com/${ENV_AZURE_TENANTID}/oauth2/logout?post_logout_redirect_uri=https://${ENV_EGATE_HOST}/cas/
cas.authn.pac4j.oidc[0].generic.id=${ENV_AZURE_APPID}

cas.authn.pac4j.oidc[0].generic.secret=${ENV_AZURE_SECRET}

cas.authn.pac4j.oidc[0].generic.auto-redirect=false
cas.authn.pac4j.oidc[0].generic.clientName=${ENV_AZURE_APPNAME}
cas.authn.pac4j.oidc[0].generic.azureTenantId=${ENV_AZURE_TENANTID}

cas.authn.pac4j.oidc[0].generic.responseType=code
cas.authn.pac4j.oidc[0].generic.useNonce=true
cas.authn.pac4j.oidc[0].generic.scope=openid profile
cas.authn.pac4j.typedIdUsed=false
cas.view.cas2.v3ForwardCompatible=true

management.endpoints.enabled-by-default = true
management.endpoints.actuatorEndpointsEnabled = true
cas.monitor.endpoints.enabled = true
cas.monitor.endpoints.sensitive = false

cas.authn.pac4j.cookie.crypto.encryption.key=${ENV_CAS_COOKIE_ENCRYPRION_KEY}
cas.authn.pac4j.cookie.crypto.signing.key=${ENV_CAS_COOKIE_SIGNING_KEY}
cas.tgc.crypto.encryption.key=${ENV_CAS_TGC_ENCRYPTION_KEY}
cas.tgc.crypto.signing.key=${ENV_CAS_TGC_SIGNING_KEY}
cas.webflow.crypto.signing.key=${ENV_CAS_WEBFLOW_SIGNING_KEY}
cas.webflow.crypto.encryption.key=${ENV_CAS_WEBFLOW_ENCRYPTION_KEY}

客户端配置 #

每个Spring Boot应用都配有spring-security.xml文件，依据Spring Security CAS官方文档编写。

已尝试操作 #

• 测试过CAS 6.x系列多个版本，问题均存在。

可能的问题原因分析 #

1. TGC Cookie属性严格性变更
   CAS 6.x对TGC（Ticket Granting Cookie）的默认属性做了更严格的限制，比如SameSite默认可能为Lax/Strict，而5.3.x版本可能默认宽松。若三个应用的子路径不同，Strict模式下TGC不会被携带到CAS服务器，导致无法识别已登录状态。建议显式配置：

cas.tgc.cookie.same-site-policy=None
cas.tgc.cookie.secure=true

注意SameSite=None必须配合secure=true，确保Cookie仅通过HTTPS传输。

2. 服务匹配逻辑调整
   CAS 6.x对服务匹配的正则校验逻辑更严格，即便使用FullRegexRegisteredServiceMatchingStrategy，也要确认应用的CAS回调地址（如/login/cas）是否被serviceId的正则覆盖。可开启CAS调试日志，查看服务匹配过程，确认请求的service是否能正确匹配已注册服务。

3. Pac4j OIDC会话联动问题
   CAS 6.x的Pac4j集成对OIDC会话管理做了调整，若OIDC会话与CAS的TGC会话未正确关联，CAS无法从OIDC会话获取已认证信息。需检查Pac4j的会话存储配置，确认id_token中的用户唯一标识（如sub）能被CAS正确关联到TGC。

4. 用户标识一致性问题
   跨应用SSO依赖CAS识别统一的用户标识，若新版本中属性释放的用户ID与旧版本不一致，或某个应用获取的用户标识无法匹配CAS会话，会触发重新认证。需确认三个应用获取的用户唯一标识属性一致，且CAS的属性释放策略正常返回该属性。

5. WebFlow流程重构影响
   CAS 6.x重构了WebFlow认证流程，默认流程可能缺少SSO会话检查步骤，导致已存在TGC时仍触发OIDC认证。需检查WebFlow配置，确保存在有效TGC时直接跳转回服务，而非重新启动认证流程。

内容的提问来源于stack exchange，提问作者Dimitris Filiopoulos