azure - 什么时候不应该使用 ACS？

Question

我一直在研究 Azure 访问控制服务 (ACS)，它看起来特别擅长处理来自异构(可配置)身份提供商的身份验证。然后，它似乎支持许多其他场景(例如，参见 ACS How-To's )。

我的问题恰恰相反:它确实可以帮助我理解 ACS 的不用途，以便正确使用它。 ACS 有哪些限制，和/或 ACS 不适合哪些场景？

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

谢谢!

Answer 1

您不应使用 ACS 作为身份提供商。

有时我会发现一些关于 ACS 所扮演的角色的困惑。 ACS 的核心是联合提供程序，但在一个有效的场景中，您希望后端服务(受信任的子系统)使用共享 key 或证书直接向 ACS 进行身份验证。这可以使用服务身份来完成。但是，我不止一次看到提出的 ACS 方案需要配置多个帐户，而这将通过为每个用户创建服务身份来实现。

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

但是 ACS 的功能不应与功能齐全的目录、身份验证和授权解决方案(例如 AD 和 ADFS)相混淆。简而言之，ACS 不是 AD/ADFS 的完美版本。