SAML 2.0跨双域依赖IdP的前端通道SLO机制问题问询

这确实属于SAML 2.0规范的一处设计疏漏。

问题背景回顾 #

依赖型身份提供商IdP#1无自有用户库，通过前端通道将登录/登出请求转发至上游IdP#2。在前端通道SLO流程中：

• 应用向IdP#1的SingleLogoutService发送LogoutRequest
• IdP#1返回页面引导浏览器向IdP#2发送LogoutRequest
• IdP#2终止会话后，引导浏览器向IdP#1的预配置ResponseLocation发送LogoutResponse
• IdP#1终止会话后，引导浏览器向应用的ResponseLocation发送LogoutResponse

当IdP#1支持多域名部署（如idp.cloudservice.com和idp.customer.corp）且Entity ID与域名无关时，IdP#2只能配置一个固定的ResponseLocation。若该地址与用户发起SLO时使用的IdP#1域名不一致，浏览器会因跨域丢失会话Cookie，导致SLO流程失败。

规范层面的矛盾 #

SAML 2.0的单点登录（SSO）流程中，AuthnRequest允许携带可选的AssertionConsumerServiceURL属性，让服务提供商可以动态指定身份响应的接收端点，完美适配多域名场景。但在SLO流程中，LogoutRequest并未定义类似的可选字段，无法为单次请求指定专属的ResponseLocation，只能依赖IdP预先配置的固定端点——这直接导致了多域名依赖型IdP的SLO流程故障。

可行的临时解决方案 #

• 跨域共享会话Cookie：若IdP#1的所有域名属于同一父域，可配置Cookie的Domain属性为父域，实现跨域名会话共享。但该方案受浏览器同源策略限制，不适用于完全独立的域名。
• 自定义扩展字段传递域名：在IdP#1转发给IdP#2的LogoutRequest中，通过Extensions字段添加自定义属性（如原请求的IdP#1域名），让IdP#2动态生成匹配的ResponseLocation。此方案需要双方IdP支持自定义扩展，属于规范外的定制实现。
• 为域名配置独立Entity ID：让IdP#1针对不同域名使用不同的Entity ID，IdP#2为每个Entity ID配置对应的ResponseLocation。但这会增加配置复杂度，且违背了“Entity ID与主机名无关”的设计初衷。

内容的提问来源于stack exchange，提问作者Heiko Theißen