何时不使用ACS？

Question

我一直在研究Azure访问控制服务（ACS），看起来它特别擅长处理来自异构（可配置）身份提供程序的身份验证。然后还有一些它似乎支持的其他方案（例如参见ACS How-To's）。

我的问题恰恰相反：为了正确使用它，它真的有助于我理解ACS 不的优点。 ACS有哪些局限性，和/或哪些情况下ACS不合适？

（假设，为了论证，我计划创建一个 - 盈利的:) - 公共Web API和相应的网站前端，托管在Azure中 - 即，我确实关心用户身份。如果您愿意，可以进一步假设我的系统将使用.NET构建。）

谢谢！

Answer 1

您不应将ACS用作身份提供者。

偶尔我会看到ACS服务的角色有些混乱。 ACS at核心是一个联合提供程序，但是有一种有效的方案，您希望您的后端服务（受信任的子系统）使用共享密钥或证书直接向ACS进行身份验证。这可以使用服务标识来完成。但是，我不止一次看到过提议配置多个帐户的ACS方案，而这将通过为每个用户创建服务标识来实现。

这不是ACS的设计方式。如果您突然拥有数千名用户，那么使ACS成为权威的源用户目录将无法扩展。 ACS提供了一个很好的规则引擎，用于规范来自各种身份提供者的传入声明类型，或者用于简单的授权策略，例如生成角色声明。

但ACS的功能不应与完全供电的目录，身份验证和授权解决方案（如AD和ADFS）混淆。简而言之，ACS不是AD / ADFS的版本。

Answer 2

即使您可以在ACS中使用Windows Live作为身份提供程序，但在某些情况下您也不希望使用它。您收到的用户ID取决于ACS名称空间。这意味着如果您的应用程序使用多个ACS名称空间（比如一个用于欧洲，一个用于美国），这可能会导致一些问题。

想象一下您的用户通过USA命名空间登录的场景。您的应用程序将收到该用户的ID（哈希），您可以在应用程序中为该用户创建配置文件。一周后，您的用户将前往欧洲，并可能通过您的欧洲名称空间登录。即使这是同一个用户，你也会得到该用户的另一个ID（哈希），这使得它看起来像是一个新用户，即使它不是。这是因为ID（哈希）取决于ACS命名空间。

Quoting an MSFT employee：

  

您从ACS获取Windows Live ID的用户ID将特定于您的服务命名空间中的该用户。如果使用其他服务命名空间，则会为同一用户获取不同的值。那么回答你的问题：   * Labs ACS和Prod ACS [不同ID]

     

  

• 不同订阅中的不同依赖方（生产中）[不同ID]

  

• 同一订阅中的不同RP [如果服务名称空间相同，则为相同ID，对于同一订阅中的2个名称空间不同   订阅]

  

• 如果我删除并重建RP到同一个域，同一个帐户[相同ID]

  

<强>更新

要回复其中一条评论，您确实无法从Windows Live身份提供商处获取电子邮件地址。但是你应该假设你无法控制从公共身份提供者那里获得的信息。一个好的做法是简单地依赖用户的标识符并为用户创建配置文件（您将在应用程序中管理配置文件）。当您从身份提供者处获得一些信息时，您已经可以更新个人资料，但如果此信息不可用，您应该只是要求用户更新他/她的个人资料。请务必查看BlobShare示例以获取更多信息。