1

背景

我正在开展一个项目，我们正在建立一个集成平台/ESB 以及一个 API 管理产品。

策略是有一个集成层，通过它处理大部分集成。这将各个系统解耦，可以在一个地方控制访问和监控。

我对 API 管理也很陌生，但已经从事企业应用程序集成多年。

设想

在第一个集成中，我们将通过 API 管理平台公开后端 API。后端 API 以及调用应用程序存在于 Internet 上，并且后端 API 使用 OAuth 2（授权类型 = 密码）进行保护。但是，没有发送任何最终用户凭据，这是一种机器对机器的流程。

我们已经获得了客户端和用户凭据，我们的想法是将其从应用程序中抽象出来，应用程序将根据 API 管理产品进行身份验证。

问题

然而，这种情况很难在 API 管理产品中实现，它似乎需要中介，因为 API 网关不能只将请求发送到后端 API，它首先需要获取令牌才能调用 API。

我发布了另一个问题（WSO2 APIM - Backend service uses OAuth 2 with Password Grant），它更关注产品，但我想从更广泛的角度同时询问这种情况。

可能的解决方案

使用 ESB 来调解流向后端 API 的 OAuth 流，并将 API 管理产品作为外观，在其中管理身份验证和其他方面以用于调用应用程序。

问题

  • 由于 API 管理产品不支持使用 OAuth 2 对后端 API 进行身份验证，我想知道这种情况是否不寻常？即在使用 OAuth 时抽象出后端 API 身份验证。
  • 这是 API 管理产品的用例吗？
  • 可能的解决方案是否合理？
4

1 回答 1

0

有两种情况很常见

                           ⌐---------------> internal services
consumer --> gateway --> esb --> gateway --> external services

和

                           ⌐---------------> internal services
consumer --> gateway --> esb --------------> external services

如果您的网关具有 OAuth 功能（在您的情况下），则首选第一个，因为通常网关用作安全实施点，并且两者的想法是相同的，封装提供者的复杂性并使其功能可用于其余部分ESB 中的服务/消费者。

顺便说一句，在云中，您应该考虑使用微服务方法而不是 ESB，因为 ESB 不能很好地扩展。

于 2017-09-29T06:58:13.593 回答