目前，我正在与 ADFS 合作在两个独立域之间建立联合信任。
我的问题很简单：ADFS v. 2.0 是否支持跨联合身份提供者的传递信任？如果是，请参阅下面的问题。（我不是在谈论 AD 林信任，而是在联合场景中使用纯 ADFS 2.0 的完全分离的域）
我知道 ADFS v 1.0 没有，如本文档第 9 页。 但在查看 ADFS 2.0 附带的声明规则时，似乎有可能，正如微软合作伙伴所证实的。 但是：关于这个主题的文档很乱！我根本找不到关于这个主题的 ADFS v. 2.0 相关声明（如果您有这方面的任何文档，请帮帮我！）。
为了更清楚，让我们假设这种场景：
Federation provider (A) trust federation provider (B) which trusts identity provider (C).
So, does (A) trust identities comming from (C) across (B)?
关于支持传递信任的进一步问题：
- 是否有可能以任何方式限制 ADFS 中的传递信任？如果可以，该怎么做？（Powershell 命令或 ADFS GUI 菜单条目在哪里找到它）
- 传递信任如何影响声明的 Issuer 和 OriginalIssuer 属性？
- 如果将传递信任与声明转换一起使用，并且提供者（B）将以将来自（C）的传入声明转换为相同类型和值的（新）声明的方式对其进行转换，这将如何影响 Issuer 和 OriginalIssuer 属性？
重要提示：无论是否支持，我都需要一些官方资料。 然而，如果没有人能够提供这些信息，而有人能够根据他的经验回答这些问题，那么即使没有官方来源，我也愿意向他/她提供赏金。
答案1
好吧，既然没人回答，我就花点时间，设置了一个测试实验室，嗅探了 HTTPS 流量。以下是我的研究结果，以防其他人遇到这种情况：
- 我仍然没有找到这个问题的官方来源
- 首先：是的，传递信任是可能的，除了法律事务之外没有其他方法可以阻止它。无论如何，适当的 SLA 是任何联合方案的基础。
- 没有特殊的“设置”来禁用或启用它，但使用声明规则引擎，如果检测到任何类型的传入声明，受信任的合作伙伴可以配置任何类型的传出声明，因此无法“保护”非法访问。
- 在我的测试中，ADFS 附带的任何规则模板均未更改声明的 OriginalIssuer 属性。有人可能会想：好吧，所以我可以使用该属性来验证任何声明的原始来源，并构建一个过滤器，以仅允许直接来自受信任合作伙伴的声明（而不是遍历，默认情况下，这仅影响 Issuer 而不影响 OriginalIssuer 属性）。但这是错误的，为什么？请看下一行。
- 正如我所说，默认模板不会触及 OriginalIssuer 属性。但您可以使用规则引擎创建自定义规则。使用规则引擎，您可以更改几乎所有声明类型、值及其属性。是的：还有 OriginalIssuer。因此，对于联合提供商来说，声明似乎直接来自受信任的合作伙伴，而实际上它们只是在那里进行了转换。
因此，我建议至少尽量减少“传递”场景（如果它们不受欢迎），方法是检查 OriginalIssuer。它不能防止传递登录，但管理员必须明确配置它 - 这将使在违反 SLA 的情况下的法律事务变得更加容易。此外，我并没有考虑将 OriginalIssuer 更改为“错误”的可能性，事实上：即使没有该功能，每个第三方软件也总是可以使其能够充当后端系统和受信任身份提供者之间的代理。例如，IdP 可以为合作伙伴 (C) 创建影子帐户 - 因此总会有一个解决方法，因为当使用联合时，您将放弃对谁能够委托特定资源访问权限的控制权。
无论如何 - 如果您和我一样好奇 ADFS 2.0 如何处理传递信任，那么现在您就知道了，而无需构建测试实验室并嗅探 HTTPS 流量。