SAML多SP实例对接单IdP应用实现双IdP SSO配置咨询

完全可行，不需要重构现有单租户部署架构，也不会破坏已经稳定运行的租户侧SAML SSO链路。

SAML 2.0协议本身没有限制单个IdP信任配置只能对接一个SP，所谓"一个IdP应用对应一个SP"只是多数IdP产品的默认配置形态，不是协议强制要求。
你只需要避开"必须给每个SP在IdP侧单独建应用"的固有思路，根据选用的内部支持IdP类型选对应落地路径即可。

方案1：IdP侧通配匹配 + SP侧链路隔离（改造成本最低，推荐优先使用） #

这个方案不需要新增任何服务节点，适配MS AD FS、Azure AD、Google Workspace等主流支持通配配置的IdP，整体改动量极小：

• 内部支持IdP侧仅需创建1个SAML应用，配置时不要写死固定的SP EntityID和ACS回调地址，改用通配规则：
  • MS AD FS/Azure AD：在应用的SP标识符（实体ID）列表添加通配规则https://*.acme.com/saml/metadata/support，ACS回调地址添加通配规则https://*.acme.com/saml/SSO/support，严格限制域名后缀为自有业务域名，避免安全风险
  • Google Workspace：创建SAML应用时开启"动态ACS URL"选项，实体ID配置为通配格式https://*.acme.com/saml/metadata/support即可
• 每个Tomcat实例的Spring SAML配置做两处小调整，完全不触碰原有租户侧SAML配置：
  • 新增一套独立的内部支持SAML链路配置，所有相关接口（元数据、ACS、单点登出）统一加/support路径前缀，和原有租户SAML链路的拦截规则完全隔离
  • 给内部支持链路单独注入MetadataGenerator和SAMLProcessingFilter实例，按当前服务器的访问域名动态拼接EntityID和ACS地址，格式刚好匹配IdP侧的通配规则，不要复用原有租户SAML链路的相关bean
  • 内部IdP认证通过后的用户权限逻辑单独走内部支持人员权限体系，不读租户侧的用户账号表，和租户登录流程完全解耦
• 后续新增单租户实例时，不需要在IdP侧做任何配置，实例启动后会自动匹配通配规则完成信任对接。

方案2：统一认证代理转发（适合长期管控、IdP不支持通配的场景） #

如果你选的内部IdP不支持通配SP配置，或者后续要给内部支持链路加统一审计、细粒度权限管控能力，可以用这个方案：

• 单独部署一个轻量SAML代理服务，绑定固定的EntityID和ACS地址，将这个唯一SP配置到内部支持IdP的单个应用中即可
• 所有单租户实例上的"内部支持登录"入口，统一跳转到代理服务的认证地址，跳转时带上签名后的目标实例地址参数
• 代理服务完成和IdP的SAML认证校验，确认是合法内部支持人员后，生成内部签名的短期身份token，重定向回目标实例的内部校验接口
• 每个Tomcat实例只需要新增一个简单的token校验过滤器，不需要改动原有Spring SAML的多IdP配置，也不需要向内部IdP暴露自身的SAML元数据
• 后续新增租户实例、调整支持人员权限、加操作审计规则，全部在代理层完成即可，不需要逐个更新租户实例的代码。

• 不要尝试让所有单租户实例共用同一个固定EntityID对接内部IdP：SAML断言的受众校验逻辑要求EntityID在IdP信任域内唯一，共用会导致断言校验失败、登录态跨实例串号的问题
• 如果用Spring Security SAML 5.x+版本做配置，记得给内部支持IdP单独创建RelyingPartyRegistration实例，不要和原有租户IdP的注册信息混在同一个配置里，避免路由匹配错误
• 内部支持链路的所有SAML接口一定要做路径隔离，不要和原有租户的SAML接口共用路径，防止过滤器链冲突影响现有租户的正常登录流程

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