与 Active Directory 集成的 .NET 应用程序的单点登录

如果开发基于 .NET 的应用程序，Microsoft 将提供一个名为 WIF 的库，该库用于以 +- 舒适的方式与 AD FS 通信（配置 + 少量代码调整，以便从 AD FS 提供的身份验证消息中获取声明）。

AD FS 2.0 和

WIF 都支持的协议很少，要使 SSO 正常工作，最常见的协议是 （afaik） SAML 2.0 和 WS 联合身份验证。两者都基于 XML 消息构建，但如果使用 WIF，则不需要知道详细信息。

对于 WS - 联合身份验证，WIF 库为 Visual Studio 提供了一个插件，该插件允许你将站点配置为 AD FS 的信赖方。

您可以使用数据库中的凭据来标识用户，实际上可以自定义 AD FS 的整个登录页面和身份验证事件。但是，基本安装要求在活动目录中定义每个用户。还可以将数据库用作声明存储（另一个数据库 AD FS 将用于向依赖应用程序提供有关用户的信息）。请注意，如果你打算在 AD FS 后面使用 AD，则你的 AD FS 服务必须能够访问它并对其进行 LDAP 查询，如果你的用户登录到 AD FS 不熟悉的本地域，我不确定这是否适合你。

如果您不需要支持行业 SSO 标准协议（我提到的 SAML 2.0），我不确定实现 AD FS 是否是一个很好的解决方案。它迫使你以某种方式工作，这并不总是那么舒适。

您的问题没有明确说明您是否仅限于使用 ADFS 来实现 SSO。ADFS当然是做到这一点的一种方式。您可能希望查看OpenID-LDAP_{^{（以前是 www.openid-ldap.org，但项目现已失效）}}和其他身份提供程序作为实现SSO的替代方案。

一种替代方法是实现使用集成窗口身份验证的 OpenID 提供程序。他们可以将其安装在DMZ中，将其暴露给互联网，而不是ADFS。 它可能允许从 Internet Explorer 和 Chrome 进行单点登录。

实现 OpenID 提供程序不是一件小事。您必须密切注意安全性。幸运的是，有许多像DotNetOpenAuth这样的框架可能会帮助你。

使用 OpenID

时，您的"云"应用程序将充当 OpenID 依赖项，并从 OpenID 提供程序获取声明的标识符以及其他属性。应将其存储在数据库中以唯一标识用户。 您可以选择实现 OpenID 提供程序，以便它还可以为您的云应用程序提供最少的信息，例如电子邮件地址、人员姓名等。

使用OpenID

的好处是，您的"云"应用程序可以继续支持其他知名的OpenID提供商，如Google和Yahoo，而无需太多变化。

最后，您需要询问您的客户他们对哪些技术感到满意。您会发现，组织之间缺乏信任（一种业务特征）往往是挑战而不是技术。

根据评论需要更多详细信息。

这里有一个很好的来源：AD FS 2.0 内容映射。

"电子书"就在这里。

我可以想象一种方案，即将云应用程序绑定到 Azure ACS，客户在其 AD 之上安装 ADFS，并将其 ADFS 与 ACS 联合。这将为您提供所需的功能。

评论后更新：

ADFS 只能针对 AD 进行身份验证。它无法对数据库进行身份验证。它可以从SQL Server DB获取属性，然后将其转换为声明，即可以使用SQL DB进行授权。

如果要针对 SQL 数据库进行身份验证，可以有两种选择。

1. 创建自定义 STS
2. 使用允许此功能的现有"自定义"STS，如身份服务器。