能否使用单一Service Provider或Relying Party为多个Web应用提供身份验证

结论 #

你提到的方案完全可行，这是SAML身份验证体系中非常成熟的网关SP（Gateway SP）/反向代理SP模式，不属于非常规设计。

方案核心优势 #

• 运维成本大幅降低：ADFS侧仅需维护1个Relying Party信任配置，上层所有Web应用无需单独适配SAML协议逻辑，仅需对接公共SP的身份校验、令牌获取接口即可，适配新应用的工作量大幅缩减。
• 安全策略统一管控：所有身份校验、会话管理、安全拦截逻辑都可以在公共SP层统一实现，比如强制MFA、异地登录拦截、会话过期策略、攻击防护等能力无需每个应用重复开发，后续迭代安全规则也仅需修改一处。

落地注意事项 #

实际落地时需要重点规避以下风险点：

• 声明透传需要做权限裁剪：ADFS给公共SP下发的是全量通用用户声明，公共SP需要根据上层应用的权限范围，裁剪后再下发给对应应用，禁止把全量敏感用户信息透传给所有接入应用。
• 可信回调与受众校验必须严格：公共SP接收ADFS返回的SAML Response后，要先校验上层应用发起请求时传递的回调地址是否在预置的可信白名单内，禁止任意地址回调，防范钓鱼跳转风险；同时给应用下发的业务令牌必须单独标记aud（受众）字段，避免A应用的令牌被用于B应用的身份校验。
• 应用会话要做好逻辑隔离：如果不需要全域统一SSO，公共SP要维护和上层应用一一对应的会话状态，避免用户在A应用登录后直接免登进入未授权的B应用。
• 提前做好高可用配置：所有接入应用的身份请求都会经过公共SP，要提前部署集群、负载均衡能力，避免单点故障导致所有应用都无法完成身份验证。

适用场景对比 #

和传统单应用单SP方案的选择逻辑如下：

• 若你方的多个Web应用均为内部自用、安全等级相近、归同一团队运维，公共SP方案的性价比远高于单应用单SP方案。
• 若接入的是对外的第三方SaaS应用、或者不同应用的安全等级差异极大（比如核心涉密应用和普通办公应用共存），还是建议单独配置对应SP和ADFS Relying Party，实现更细粒度的信任隔离。

内容的提问来源于stack exchange，提问作者Vlogs and videos with Eraj Raj