Azure ACS - 最佳实践实施

Question

我们正在从头开始构建一个在 Windows Azure 上运行的 ASP.NET MCV 3 应用程序。关于身份验证和授权层，我们正在考虑使用访问控制服务。我浏览了一些关于 ACS 的文章，在那里我得到了基本的想法，但我仍然对它有一些疑问。

我的理解是，使用 ACS 我们将身份验证过程外包给一个或多个身份提供者 (IP)，基本上我们信任另一个系统（即 Microsoft Live ID）来验证我们的用户。

基本过程非常简单：在身份验证阶段，我们将用户重定向（ACS 执行此操作）到我们的“受信任”IP 之一，这会将用户（使用有效令牌）重定向到 ACS 并最终重定向到我们的应用程序.

这里有几个问题：

由于我们不希望所有拥有 Live ID 帐户的用户都可以访问我们的应用程序，我认为应该有另一个流程来验证该用户并检查他是否已在我们的应用程序中注册。问题是在哪里？在 ACS 中还是在我们的应用程序中？

我对此有一个想法，但我不知道这样做是否正确：

在注册阶段，系统（我们的网络应用程序）询问用户他想使用哪个 IP（即 Live ID、Google、Facebook 和我们的应用程序）在应用程序中验证自己。然后用户在 IP 系统上进行身份验证过程，当他回来时，我们将他的用户名（IP 用户名）存储在我们的数据库中。 因此，下一次，在身份验证阶段，我们可以检查该用户是否已在我们的系统中注册。

如果上述理论是正确的，那就意味着在我们的应用程序中。我们需要建立我们的会员提供商来存储来自 IP 和选择我们应用程序的用户的用户名。作为IP。 我对么？设计上述流程的最佳做法是什么？

现在让我们谈谈授权和“角色”。它如何与 ACS 一起工作？ ACS 是否为每个用户管理多个角色？

我的理解是，使用 ACS，您可以创建多个与 IP 而不是单个用户相关的“规则组”。如果这是正确的，我们如何管理应用程序中的角色用户？例如，假设我们有多个角色，并且我们的用户可以与这些角色相关联，我们可以使用 ASC 来管理它吗？

所以最后的问题是：ACS 本身是否涵盖了整个身份验证和授权过程？我们还需要使用 .net Membership Provider 吗？为了满足我们的要求，最佳做法是什么？

Answer 1

用户验证过程通过声明完成。

在您使用 ACS 设置 IP 后，当用户进行身份验证时，ACS 将从该 IP 获取有关经过身份验证的用户的声明。您需要在 ACS 中配置规则以说明您希望将哪些声明转发到您的应用程序。您还可以将声明转换为不同的类型，以将传入的声明集规范化为您的应用程序所期望的

如果您想使用 ACS 实施基于角色的访问，您可以。在这种情况下，角色只是 ACS 将发出的另一个声明，您将根据从 ACS 收到的角色声明实现您的应用程序以授予用户权限。

您可以配置将某些 IP 输入声明映射到角色输出声明的 ACS 规则。 ACS 还有一个管理服务可以更改这些规则，因此您可以实施用户注册过程。

ACS 中的单个声明规则与发出声明的身份提供者相关，但规则组不相关。与 RP（您的应用程序）关联的规则组。规则组只是一组声明转换规则，它们告诉 ACS：“对于此应用程序，在颁发令牌时应用此规则组策略”。

ACS 文档对 ACS 声明规则配置有很多话要说，无论是通过门户网站还是通过管理服务：

https://msdn.microsoft.com/library/azure/hh147631.aspx

扩展响应：

假设您使用 ACS 对使用 WIF 的 ASP.NET 应用进行身份验证。您可以将 ACS 配置为使用电子邮件“jdoe@gmail.com”为 google 用户发出“经理”的角色声明。

现在，在您的 ASP.NET 应用程序中，WIF 将看到此角色声明，它允许您使用 HttpContext.Current.User.IsInRole("Manager") 或 web.config 等效项来控制访问。

您可以使用 Web UI 手动管理这些 ACS 规则，也可以使用 ACS 管理服务实施注册过程，以编程方式将此类规则添加到 ACS。 acs.codeplex.com 上提供了一些 ACS 管理服务示例。

此外，身份开发人员培训工具包有一些关于基于 WIF 角色的访问的示例：

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347

Answer 2

关于注册阶段的部分问题，最好使用NameIdentifier声明类型来识别用户

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.

这对于每个身份提供者来说应该是唯一的并且也是固定的。如果您使用电子邮件地址声明，它可能会因同一用户而改变。从技术上讲，两个身份提供者可以使用相同的NameIdentifier（ACS 的开箱即用的都没有），因此您可以将 NameIdentifier 声明与 IdentityProvider 声明类型结合使用

http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider

保证唯一性。

关于角色的部分，我想说使用 ACS 从像 Google 这样的通用身份发出角色声明将很难使用 ACS 中的声明转换规则在每个用户的基础上进行管理。您必须为每个注册用户添加一个规则 - 可能不可行。我认为 ACS 规则组更适合角色声明的转换（例如，由联合 ADFS 发布）。恕我直言，您在应用程序中执行此操作的想法更好。在代码中，使用 WIF 执行此操作的位置是自定义 ClaimsAuthenticationManager。您覆盖其Authenticate 方法并基于传入原则的NameIdentifier 声明，在您的会员数据存储中查找并根据您的会员数据库中的角色创建一个新的IClaimsPrinciple（即您添加一个角色为用户所在的每个角色声明）。

然后您在自定义ClaimsAuthorizationManager 中做出授权决定。网上有一些很好的示例和信息。你可以从

http://msdn.microsoft.com/en-us/library/ee748497.aspx