如何在微服务和 API 网关架构中对不同的配置文件进行身份验证和授权

Posted 2023-03-28

【中文标题】如何在微服务和 API 网关架构中对不同的配置文件进行身份验证和授权

【英文标题】：How to authenticate and authorize different profiles in a microservices and API Gateway architecture

【发布时间】：2018-08-09 15:18:09

【问题描述】：

我想构建一个微服务架构。它应该有 13 个微服务和 3 个客户端（2 个 Web 和 1 个移动）。

在我们的场景中，我们有：

员工：对特定和共享服务的访问权限及其凭据存储在 Active Directory 中； 管理员：他们是具有完全访问权限的员工。他们拥有特定的共享服务，并且他们的凭据存储在 Active Directory 中； 客户：对特定和共享服务的访问权及其凭据存储在 Identity 微服务中。

我们将拥有一个 API 网关。

每个请求都由 API Gateway 处理，API Gateway 应该（或调用负责人）检查请求的令牌是否有效，识别它是客户、员工还是管理员，并检查该用户是否有权访问请求 API /微服务。

我对这个解决方案有一些误解，所以我希望能得到一些帮助：

API 网关的职责是什么？ 什么是身份微服务职责？ 如何定义员工、客户和管理员可以访问或不可以访问哪些 API/微服务？ 如何识别给定用户是客户、员工还是管理员？

【参考方案1】：

API 网关的职责是什么？

API 网关可以理解为一种服务，它位于所有其他服务之前，让您将这些服务公开给客户端。 在这样做的过程中，它允许所有流量通过它自己，因此它可以做很多事情，比如

安全性 日志记录 路由 版本控制 转型

您有一个带有标头的传入请求，您需要将其传递给实际处理该请求的下游服务。 API 网关几乎可以完成上述所有操作。

什么是身份微服务职责？

身份是帮助您唯一识别用户的一组数据。在您的情况下，您有 Active Directory，其中包含所有员工的身份信息。同样，您可以保留有关客户的信息就是这样一种服务。身份应全权负责帮助您识别他的用户的基本人口统计信息。除此之外，此类服务可能需要提供有关使用身份的安全性。

身份可以具有角色，并且服务在相互通信时需要传递向下游服务告知身份的信息，以及该服务可以验证正在传递的身份信息的某种方式。

这就是 OAuth 发挥作用的地方，如果您添加身份、身份提供者和授权，您将获得称为 OIDC 或 OpenID Connect 的东西

有了这个，您应该能够为您的每个身份定义角色，然后让各个服务决定具有特定角色的特定身份可以做什么或不能做什么。

如何识别给定用户是客户、员工还是管理员？

好吧，您可以使用角色来识别（如果您可以将角色添加到您的身份），或者让您的身份服务为您回答这个问题。 传递 userId 并让服务根据此用户数据的来源告诉您它是什么类型的用户。 除非我有更多的见解，否则很难回答这个问题。

【讨论】：

完美。 API Gateway 负责什么样的安全性？因此，您建议针对身份、客户和员工及其特定数据提供不同的服务。正确的？响应是否必须包含角色、范围和声明？为什么？

API Gateway 可以剥离安全性的请求。它有点复杂，因为您需要放弃身份验证但保留授权。但它可以说用户就是他声称的那个人，并且下游的任何人都不需要检查它。可以减少几毫秒。 2. 呼叫是您的，但由于所有这些都只是一个身份，因此我将拥有一个具有多个租户的服务，并在此之后封装外部 Active Directory。 3.响应不必。请求应包含带有身份、角色和声明的标头信息。