ADFS v.2.0在联合scheme中传递的信任

目前，我正在与ADFS一起在两个分离的域之间build立联合信任。

我的问题很简单： ADFS v。2.0是否支持跨联合身份提供者的传递式信任？ 如果是这样，请参阅下面的问题。 （我不是在谈论AD森林信任，而是在联盟情况下使用纯ADFS 2.0的完全分离的域）

我知道ADFS v 1.0并不像第9页上的文档中所述的那样。但是，从ADFS 2.0的索赔规则来看，它似乎是可能的，正如微软合作伙伴所证实的那样。但是：关于这个主题的文档是一团糟！根本没有关于这个话题的ADFS v.2.0相关的声明，我能够find（ 如果你有任何关于这个问题的文档，请帮我一把！ ）。

为了更清楚，我们假设这种情况：

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菜单条目在哪里可以find它）
可传递的信任如何影响索赔的发行人和原始伊索尔特性？
如果传递性信任和声明转换一起使用，提供者（B）会将（C）中的所有声明转换成相同types的（新）声明价值，那么这将如何影响发行人和原始伊索尔特性？

重要说明：无论是否支持，我都需要一些官方消息来源。 但是，如果没有其他人能够提供他们，而且有人能够以他的经验来回答这些问题，那么即使没有官方消息来源，我也愿意为他们提供赏金。

那么，由于没有人回答，我花时间，设置了一个testing实验室，并嗅探HTTPSstream量。以下是我的研究成果，以防其他人会遇到这个事情：

这个问题我还没有官方的消息
首先：是的，传递信任是可能的，除法律事务外，没有办法阻止它。 propper SLA无论如何都是任何联盟场景的基础。
没有特殊的“设置”来禁用或启用它，但是使用声明规则引擎，值得信赖的合作伙伴可以configuration任何types的传出声明。如果检测到任何types的传播声明，所以没有办法“保护”非法访问。
在我的testing中，没有任何ADFS附带的规则模板更改了声明的OriginalIssuer属性。有人可能会认为：好吧，我可以使用该属性来validation任何索赔的原始来源，并build立一个filter，只允许直接从（而不是通过遍历，默认只影响发行人，但不是OriginalIssuer属性）可信赖的伙伴但那是错的，为什么？看下一行。
正如我所说，默认模板不要触摸OriginalIssuer属性。但是您可以使用规则引擎创build自定义规则。使用那个，你可以改变几乎所有的索赔types，价值和他们的属性。是的，也是OriginalIssuer。所以对于联邦提供商来说，它看起来像是从值得信赖的合作伙伴那里直接获得的，实际上他们只是在那里转变。

所以，我build议至less尽量减less“传递”情况，如果他们不想要的，是检查OriginalIssuer。它不能防止传递login，但是pipe理员必须明确地configuration它 – 这将使得在SLA排除的情况下合法的affiars更容易。另外，我并没有想到可以将OriginalIssuer作为一个“bug”来改变，实际上，即使没有这个function，每一个第三方软件都可以使它能够作为后端系统和可信身份提供者之间的代理。例如，IdP可以为合作伙伴（C）创build影子帐户，所以总是会有一个解决方法，因为在使用联邦时，您将放弃对谁能够将访问权限委托给特定资源的控制权。

无论如何 – 如果您像我一样对ADFS 2.0如何处理传递信任感到好奇，现在您知道，无需构buildtestlab并嗅探HTTPSstream量。