WSTrustChannelFactory对接ADFS时添加作用域证书的目的及使用疑问

我来帮你拆解这个问题——在和ADFS通信时给WSTrustChannelFactory的ServiceCertificate.ScopedCertificates集合添加证书的作用，以及你发现的「随便用证书都能正常运行」的疑惑。

一、作用域证书的核心设计目的 #

这个集合的初衷是为不同的服务端点URI指定对应的服务证书，主要用于两个关键安全场景：

• 加密发给ADFS的敏感请求数据：比如请求里的客户端凭证、需要保密的令牌参数，确保只有目标ADFS服务能解密这些内容。
• 验证ADFS返回响应的合法性：确认响应是由合法的ADFS服务签发，且内容没有被篡改。

不过这里要注意你使用的ADFS端点（http://myadfs/adfs/services/trust/13/windows）是Windows身份验证端点，它的安全机制比较特殊——依赖Windows集成认证（NTLM/Kerberos），这种场景下默认的安全流程已经覆盖了通信加密和身份验证，所以很多时候即使随便指定证书甚至不指定，程序也能正常运行。

二、你的代码里这个证书是否被实际使用？ #

要分场景判断：

• 如果你的绑定配置的是消息安全模式（比如Message模式的WS2007HttpBinding），这个证书会被用来加密请求敏感部分，同时验证ADFS的响应签名。
• 但你用的是Windows端点，通常绑定会配置成TransportWithMessageCredential或基于Windows集成认证的Transport模式，此时：
  1. 通信加密靠HTTPS（如果是HTTPS端点）或Windows集成认证的加密机制完成，不需要这个证书。
  2. ADFS响应的签名验证，默认会自动从ADFS元数据中获取签名证书，而非你手动添加的作用域证书。

这就是为什么你发现「用任何证书都能正常运行」——在这个特定的Windows端点场景下，你添加的这个证书其实没有被实际调用。

三、遗留代码这么写的可能原因 #

• 大概率是当初开发时混淆了不同ADFS端点的安全需求：比如把适用于UserName端点的配置套用到了Windows端点上（UserName端点通常需要手动指定证书来加密密码）。
• 也有可能是为了兼容旧版ADFS或者预留其他安全模式的扩展空间，但现在的ADFS版本已经可以自动从元数据获取所需证书，无需手动配置。

内容的提问来源于stack exchange，提问作者Søren Larsen