【发布时间】：2012-12-24 17:08:42
【问题描述】：
全部，
我已经阅读了大量有关基于声明的身份验证的内容，但仍然有些困惑。我正在努力巩固我的理解，特别是与 SharePoint 2010/2013 相关，但也普遍（即 ASP.NET）。
我对各种技术术语的理解如下：
WIF (Windows Identity Foundation) - 一个 .NET 库（API 集），用于使用身份声明和构建自定义 STS 等。
信赖方 - 声明的“消费者”（即 SharePoint、ASP.NET 网站等）。声明通过 STS（仅 IP-STS？）提供。
-
STS (Security Token Service) - 一种发布安全令牌的专用 Web 服务。有两种口味，有些 STS 可能同时有两种口味？
- RP-STS（依赖方安全令牌服务）
- IP-STS（身份提供商安全令牌服务）
可信身份提供者（SharePoint 术语）- 又名。 IP-STS。
SharePoint 2010/2013 STS - 使用 WIF 开发的 SharePoint 服务应用程序，仅充当 RP-STS。充当许多用户可配置的可信身份提供者 (IP-STS) 的可插入聚合点。如果需要，这些可以使用 WIF 手工构建。
ADFS 2.0 - 一个 Windows 角色，专门设计用于仅针对 Active Directory 实例联合组织。公开使用 WIF 构建的 IP-STS 端点。我对 ADFS 2.0 的理解是它不允许您“聚合”其他身份提供程序 - 它只允许您针对可能不是本地的特定 AD 实例进行身份验证，因此需要联合以支持 SSO .
Windows Azure ACS 2.0 - 一种专门用于联合任何已配置的第三方身份提供程序（即 Microsoft 帐户、Google、Facebook、ADFS 2.0）的服务。作为其他身份提供者的可插入聚合点，它的行为有点像依赖方。公开使用 WIF 构建的 IP-STS 端点。它聚合的身份提供者不一定是 IP-STS，但 ACS 2.0 使用其内置的 IP-STS 通过声明公开所有内容。
SharePoint 2010/2013 问题：
我的主要问题是，我看到了一些关于 ADFS 2.0 和 SharePoint 的文章，这些文章读起来几乎就像您用 ADFS 2.0 替换内置的 SharePoint 2010/2013 STS！希望这只是我的阅读，但它混淆了我的理解。
- 你真的能做到这一点吗？如果您真的想要，我认为您没有理由不这样做，但我认为您需要禁用 SharePoint STS 并进行大量手动配置？
- 您为什么要这样做？
2.1。 SharePoint STS 已经支持 AD 身份验证作为 OOTB 受信任的身份提供程序选项，如果您想使用 ADFS 2.0，您可以将其添加为受信任的身份提供程序 (IP-STS)，我已经看过博客文章。
2.2。根据我对 ADFS 2.0 的描述，将其更改为 SharePoint STS 实际上会给您提供一个不太灵活的解决方案？
声明：
- 您可以将 SharePoint STS 配置为使用 ADFS 2.0 作为受信任的身份提供程序 (IP-STS) 以及或代替本地 AD。
- 您可以将 SharePoint STS 配置为使用 Windows Azure ACS 2.0 作为受信任的身份提供程序 (IP-STS)。这将使支持第三方身份验证提供商变得非常容易，而无需使用 WIF 开发您自己的 IP-STS。
ASP.NET WIF 问题：
- 我的理解是，为了执行信任协商和声明交换，RP-STS 必须与 IP-STS 通信。它是否正确？
- 因此，在使用 WIF 构建基于声明的 ASP.NET Web 应用程序（依赖方）的上下文中，您是否可以开发/重用并将 RP-STS 包含到应用程序中，并将其配置为与IP-STS？如果不能，您可以使用 WIF 直接从 IP-STS 获取身份吗？
只是写这篇文章帮助我摆脱了这个问题，但任何关于不准确/过于简单化/完全不真实的帮助将不胜感激！
问候，
迈克尔·泰勒
【问题讨论】：
标签： wif claims-based-identity acs adfs2.0 claims