我一直在研究 Azure 访问控制服务 (ACS)，它看起来特别擅长处理来自异构（可配置）身份提供者的身份验证。然后，它似乎支持许多其他方案（参见例如ACS How-To's）。
我的问题是相反的：它真的可以帮助我理解为了正确使用它，ACS不适合什么。ACS 的局限性是什么，和/或在哪些情况下 ACS 不合适？
（假设，为了论证，我计划创建一个 - 有利可图的 :) - 公共 Web API 和相应的网站前端，托管在 Azure 中 - 即，我确实关心用户身份。如果您愿意，您可以进一步假设我的系统将使用 .NET 构建。）
谢谢！
您不应将 ACS 用作身份提供者。
有时，我对 ACS 所扮演的角色感到有些困惑。ACS at is core 是一个联合提供者，但在一个有效的场景中，您希望您的后端服务（受信任的子系统）使用共享密钥或证书直接向 ACS 进行身份验证。这可以使用服务标识来完成。然而，我不止一次地看到一个 ACS 场景提出了要配置多个帐户的情况，这将通过为每个用户创建一个服务身份来实现。
这真的不是 ACS 的设计方式。如果您突然拥有成千上万的用户，那么将 ACS 设置为您的权威源用户目录将无法扩展。ACS 提供了一个很好的规则引擎，旨在规范来自各种身份提供者的传入声明类型，或用于简单的授权策略，例如生成角色声明。
但 ACS 的功能不应与 AD 和 ADFS 等功能齐全的目录、身份验证和授权解决方案相混淆。简而言之，ACS 不是 AD/ADFS 的版本。
尽管您可以在 ACS 中使用 Windows Live 作为身份提供者，但在某些情况下您不想使用它。您收到的用户 ID 取决于 ACS 命名空间。这意味着如果您的应用程序使用多个 ACS 命名空间（假设一个用于欧洲，一个用于美国），这可能会导致一些问题。
想象一下您的用户通过您的 USA 命名空间登录的场景。您的应用程序将收到该用户的 ID（哈希），您可能会在您的应用程序中为该用户创建一个配置文件。一周后，您的用户前往欧洲并可能通过您的欧洲命名空间登录。即使这是同一个用户，您也会得到该用户的另一个 ID（哈希），这看起来像是一个新用户，即使它不是。这是因为 ID（哈希）取决于 ACS 命名空间。
您从 ACS for Windows Live ID 收到的用户 ID 将特定于您的服务命名空间中的该用户。如果您使用不同的服务命名空间，您将为同一用户获得不同的值。因此，回答您的问题：* Labs ACS 和 Prod ACS [不同 ID]
不同订阅中的不同依赖方（在产品中）[不同 ID]
同一订阅中的不同RP [如果服务命名空间相同，则ID相同，同一订阅中的2个命名空间不同]
如果我删除并重建 RP 到同一个领域，同一个帐户 [同一个 ID]
更新：
要回复其中一条评论，您确实不会从 Windows Live 身份提供商那里获得电子邮件地址。但是您应该假设您无法控制从公共身份提供者那里获得的信息。一个好的做法是简单地依赖用户的标识符并为用户创建配置文件（您将在应用程序中管理配置文件）。当您从身份提供者处获得一些信息时，您已经可以更新个人资料，但如果此信息不可用，您应该简单地要求用户更新他/她的个人资料。请务必查看BlobShare示例以获取更多信息。