我们有一个供应商提供的解决方案，该解决方案需要用户名和密码才能利用作为 Web 服务公开的 API。它们将包含在调用的实际 xml 中。我们显然不喜欢那样。
有没有人知道任何产品、系统等等，我们可以让调用系统使用基于令牌的安全性对其进行身份验证，然后注入用户名密码并将请求转发到产品可访问但外部不可访问的安全区域来电者。当然，通过返回响应。
【问题讨论】：
标签： web-services security authentication proxy inject
我会支持@identigral STS 提案。正如@identigral 提到的，建议使用一些身份管理 (IdM)，例如 Keycloak 来提供 OAuth 2.0 令牌，并在不久的将来说服您的供应商使用一些 IdM。要查看有关如何生成 Keycloak 令牌 check this repo 以及此 Stackoverflow question 的示例。对于您的用例，我看到了三种可能的解决方案：
如果您使用 Java 进行开发，我会选择 API 网关，例如 Netflix Zuul。 Spring framework supports Zuul 并申请 OAuth 2.0 tokens to Zuul is a very good option。对于配置部分，Spring 提供了Cloud Config 来存储组件的全局配置，它可以很容易地与 Zuul 连接。
使用一些商业工具，例如Google Apigee。看一下，第 1 点中描述的所有内容。）都可以使用 Apigee 在 API 级别进行配置，涵盖多种编程语言。
任何解决方案都可能对您有好处，这取决于您的具体用例。
【讨论】：
身份验证/代理 服务有一个名称 - 安全令牌服务 (STS)。 oAuth 令牌交换工作草案对 STS 及其用途做了很好的总结：
安全令牌服务 (STS) 是一种能够验证 提供给它的安全令牌并在 响应，使客户端能够获得适当的访问权限 异构环境中或跨环境的资源凭据 安全域。
Web 服务客户端已使用 WS-Trust [WS-Trust] 作为与 STS 交互以进行令牌交换的协议。尽管 WS-Trust 使用 XML 和 SOAP，现代 Web 开发的趋势已经 一直致力于 RESTful 模式和 JSON。 OAuth 2.0 授权 框架 [RFC6749] 和 OAuth 2.0 Bearer Tokens [RFC6750] 已经出现 作为授权第三方应用程序访问的流行标准 到 HTTP 和 RESTful 资源。
传统的 OAuth 2.0 交互 涉及资源所有者的某些表示的交换 访问令牌的授权，这已被证明是一个非常 在实践中有用的模式。但是，它的输入和输出是 有点过于受限，无法完全容纳安全令牌 交换框架。
大多数 STS（包括 oAuth 令牌交换草案指定的类型）不处理异构令牌，因为您的用例需要超出 oAuth 到 SAML 或反之亦然。您的用例的解决方案很可能涉及自定义编码的 STS。我们已经为使用各种产品/堆栈/平台/等的客户实施了 STS，可将 oAuth/SAML 转换为任何内容（例如，带有自定义凭证标头的 SOAP）。
我们经常使用 Salesforce 作为平台，它提供了许多有助于此用例的管道。公平地说，类似的管道可用于相当多的平台和堆栈——从三大平台（AWS/GCP/Azure）到具有适当库的 Java/Python/Ruby/Node/Go，再到 Keycloak 等身份和访问管理产品。
【讨论】：