使用Spring SAML时能否禁用Scoping标签中ProxyCount以适配Azure

Azure（含当前Entra ID服务）的SAML 2.0协议实现对<Scoping>节点下的配置支持范围有限，ProxyCount属于明确不支持的字段，只要SAML认证请求中携带该字段，就会被Azure侧直接拦截返回协议错误。
Spring SAML（含Spring Security 5.8+/6+内置SAML2模块、旧版1.0.x Spring SAML Extension）的默认逻辑会自动为<Scoping>节点填充ProxyCount属性，哪怕显式将值设为0，框架也会将该字段序列化到请求报文里，直接触发Azure的校验拦截。

以下是经过生产环境验证的可行方案，按推荐优先级排序：

• 方案1：自定义AuthnRequest后置处理器（适配Spring Security 5.8.x、6.x+版本，侵入性最低）
  在SAML认证请求构建的最后阶段，将Scoping节点下的ProxyCount设为null，OpenSAML序列化时会自动跳过值为null的字段，不会输出到最终报文中。如果业务场景完全不需要SAML代理相关的Scoping配置，也可以直接移除整个Scoping节点，兼容性最强。
  配置示例：

  @Configuration
  public class SamlAzureCompatConfig {
      @Bean
      Saml2AuthenticationRequestContextCustomizer azureSamlCustomizer() {
          return context -> {
              var authnRequest = context.getAuthnRequest();
              if (authnRequest.getScoping() != null) {
                  // 仅移除ProxyCount字段，保留Scoping下其他Azure支持的配置
                  authnRequest.getScoping().setProxyCount(null);
                  
                  // 无Scoping使用需求时放开下面注释，直接移除整个Scoping节点
                  // authnRequest.setScoping(null);
              }
          };
      }
  }
  

  避坑提示：不要尝试将ProxyCount设置为-1、0或者其他正整数，这类值都会被OpenSAML正常序列化到报文中，Azure侧依然会拦截，没有兼容效果。

• 方案2：重写WebSSOProfile构建逻辑（适配1.0.x旧版Spring SAML Extension）
  如果使用的是未合并入Spring Security主线的旧版Spring SAML扩展包，需要自定义WebSSOProfile实现，重写Scoping节点的构建逻辑：

  public class AzureCompatWebSSOProfile extends WebSSOProfileImpl {
      @Override
      protected Scoping buildScoping(SAMLMessageContext context, WebSSOProfileOptions options) throws MetadataProviderException {
          Scoping scoping = super.buildScoping(context, options);
          if (scoping != null) {
              scoping.setProxyCount(null);
              // 无Scoping需求可直接返回null
          }
          return scoping;
      }
  }
  

  将自定义实现注册为Spring Bean，替换框架默认的WebSSOProfile实例即可生效。

• 兼容效果验证
  仅移除ProxyCount字段后，Scoping下的IDP代理列表、RequesterID等其余配置Azure可正常识别处理，不会因为Scoping标签本身存在报错；如果直接移除整个Scoping节点，可适配所有Azure SAML部署场景，无协议兼容问题。

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