今天，我很高兴宣布 Application Load Balancer (ALB) 提供内置的身份验证功能。ALB 现在可以在用户访问应用程序时安全对其进行身份验证，开发人员不必再编写支持身份验证的代码，也不必承担从后端进行身份验证的责任了。我们的团队构建了一个非常精彩的演示示例，您可以利用该实例尝试身份验证功能。

身份安全性是现代应用程序的重要组成部分，随着客户不断将关键任务型应用程序迁移到云中，开发人员需要反复编写相同的身份验证代码。企业想在云应用程序中使用本地身份。Web 开发人员希望使用社交网络中的联合身份来支持用户登录。ALB 全新的身份验证操作使用 Amazon Cognito 通过 Google、Facebook 和 Amazon 等社交身份提供商 (IdP) 提供身份验证。此外，它还与符合 OpenID Connect 协议的所有 IdP 原生集成，跨应用程序提供安全身份验证和单一登录体验。

ALB 身份验证如何运作？

身份验证是一个很复杂的主题，读者对该主题的了解程度可能各不相同。我希望通过介绍几个关键概念，确保我们达成共识。如果您已经是身份验证专家，只想了解 ALB 身份验证的工作原理，可以跳转到下一部分！

身份验证用于验证身份。
授权用于验证权限，即某个身份可以执行的操作。
OpenID Connect (OIDC) 是基于 OAuth 2.0 协议构建的简单身份或身份验证层。OIDC 规范文档写得非常好，闲暇时可以看看。
身份提供商 (IdP) 管理身份信息并提供身份验证服务。ALB 支持符合 OIDC 的所有 IdP，您可以使用 Amazon Cognito 或 Auth0 等服务聚合来自不同 IdP（例如 Active Directory、LDAP、Google、Facebook、Amazon 或者在 AWS 中或本地部署的其他 IdP）的身份。

抛开术语来说，上述所有内容可以简单理解为：用户身份以及用户可以执行哪些操作。做到安全有效地验证身份很困难。传统方法是：企业将名为 SAML 的协议与其 IdP 配合使用，以此来为内部用户提供单一登录 (SSO) 体验。SAML 中包含大量 XML，而现代应用程序已开始使用 OIDC 和 JSON 机制来共享声明。开发人员可以将 ALB 中的 SAML 与 Amazon Cognito 的 SAML 支持结合使用。Web 应用程序或移动开发人员通常通过社交 IdP（例如 Facebook、Amazon 或 Google）使用联合身份，而这些社交 IdP 正好也受 Amazon Cognito 支持。

ALB 身份验证的工作方式是在侦听器规则中定义身份验证操作。ALB 的身份验证操作将检查传入请求中是否存在会话 Cookie，如果有，则检查其是否有效。如果会话 Cookie 已设置并且有效，则 ALB 会将该请求路由到设置了 X-AMZN-OIDC-* 标头的目标组。标头包含 JSON Web Token (JWT) 格式的身份信息，后端可以使用该信息来识别用户。如果会话 Cookie 未设置或者无效，则 ALB 将遵照 OIDC 协议，向身份提供商发出 HTTP 302 重定向。该协议的内容量很大，相应文档对此进行了更全面的介绍，感兴趣的读者可以阅读。

ALB 身份验证演练

我有一个简单的 Python Flask 应用程序位于 Amazon ECS 集群中，该集群在一些 AWS Fargate 容器中运行。这些容器位于 ALB 要路由到的目标组中。我需要确保应用程序用户在访问需要身份验证的应用程序部分之前先登录。首先，我导航到控制台中的 ALB 并编辑规则。

我需要确保对 /account* 终端节点的所有访问均经过身份验证，因此，我添加一个新规则，其中包含匹配这些终端节点的条件。

现在，我要添加一条新规则，并在该规则中创建一个 Authenticate 操作。

我提供一些配置详细信息，让 ALB 创建一个新的 Amazon Cognito 用户池。

创建了 Amazon Cognito 池后，我可以在高级设置中进行一些其他配置。

我可以更改默认的 Cookie 名称、调整超时、调整范围，以及选择适合未经身份验证的请求的操作。

我可以选取“Deny”以便为所有未经身份验证的请求提供 401，也可以选取“Allow”，指定哪些操作可以在未经身份验证的情况下传递到应用程序。这对于单页面应用程序 (SPA) 很有用。现在，我要选择“Authenticate”，这将提示 IdP（本例中为 Amazon Cognito）对用户进行身份验证并重新加载现有的页面。

现在，我要为目标组添加转发操作并保存该规则。

在 Facebook 端，我只需将 Amazon Cognito 用户池域添加到白名单 OAuth 重定向 URL 即可。

对于其他身份验证提供商，我将按照类似的步骤进行操作。

现在，当我导航到经过身份验证的页面时，Fargate 容器会收到 ALB 设置了 X-Amzn-Oidc-* 标头的原始请求。我的应用程序可以使用这些标头中的信息（claims-data、identity、access-token）实施授权。

不必编写一行代码来处理每个 IdP，即可实现上述所有操作。但是，为了确保请求未被篡改，验证 JWT 标头上的签名对于实施应用程序来说仍然很重要。

其他资源

当然，我们今天展示的所有内容也可以在 API 和 AWS 命令行界面 (CLI) 中实现。有关该功能的其他信息，请参阅相应文档。

另外，请确保查看演示示例。

将身份验证功能内置到 ALB 中后，开发人员可以集中精力构建应用程序，而不必为每个应用程序重建身份验证，同时还可以确保 ALB 的扩展性、可用性和可靠性。我认为这项功能真的很棒，已经迫不及待想看到客户使用它来构建什么了。请在评论区或 Twitter 上发表您对这项功能的看法！

作者介绍：
Randall Hunt
AWS 全球高级布道师。此前供职于 NASA, SpaceX 及 MongoDB。

本文转载自AWS技术博客。

原文链接：
https://amazonaws-china.com/cn/blogs/china/built-in-authentication-in-alb/

创作场景

使用 Application Load Balancer 内置的身份验证功能简化登录流程