我正在寻找一个 API 管理系统，它将与 Keycloak 集成（Keycloak 应该提供所有身份验证）。Wicked.io（基于kong）看起来不错。
我尝试将 oAuth2 添加为身份验证方法，但 wicked 不断生成自己的客户端 ID 和机密。
有没有办法用邪恶的方法做到这一点？
问问题
172 次
1 回答
0
wicked.haufe.io 的维护者在这里。
将 wicked/Kong 与 KeyCloak 结合起来可能不是一个好主意。Wicked 解决了 KeyCloak 打算解决的许多问题，而且重叠非常大，例如对 OAuth2 工作流程进行身份联合（SAML、OAuth2）等等。
KeyCloak 和 wicked/Kong 遵循不同的原则；KeyCloak 颁发令牌，这些令牌通过您服务内的 KeyCloak 库进行验证。这或多或少取代了 API 网关 - 它基于 KeyCloak 库在您的服务中实现。
wicked/Kong 作为对比的建立方式不同，其中最大的区别是 wicked 在 Kong 之上提供的 API 门户，并且您拥有专用的 API 网关 (Kong)。Wicked 为您提供自己的客户端凭据，并且它还希望完成整个身份验证和授权位。您得到的交换是自助服务 API 门户；如果你不需要那个，你可能就不需要 wicked。
您可以做的是通过让 KeyCloak 充当 SAML 或 OAuth2 身份提供者，将 KeyCloak OAuth2 流联合到 wicked 中。然后，您将 KeyCloak 授权服务器注册为具有 wicked 的身份提供者（使用单个服务提供者 (SAML) 或客户端 (OAuth2)）。这里的“但是”是您仍然需要提供一个不通过 KeyCloak 库的服务的入口点。
wicked/Kong 总是这样工作：它消除了在您的服务中实现身份验证/授权的需要；相反，您需要检查标题X-Authenticated-UserId和X-Authenticated-Scope. 对于 wicked，这通常包含类似 的内容sub=<some id>，这也取决于您配置 wicked 使用的身份提供者类型。但这种方法通常会取代KeyCloak。好处是您可以有一个单一的服务入口点（=Kong），并且您有一种非常轻量级的方式来保护任意服务 - 不仅是用 KeyCloak 支持的语言编写的服务！- 在 API 网关后面，同时通过 API 门户提供自助服务访问（带有可配置的计划、文档……）。
所有这些事情显然有些复杂。wicked 的使用非常灵活，但它并不是真的要与 KeyCloak 结合使用（同样如此。这一切都归结为真正理解用例并找到以最佳方式解决您的用例的解决方案架构。
如果您的用例涉及 API 门户和 API 文档（应该），那么使用 wicked/Kong 可能是一个不错的选择。如果没有，您可能会更乐意坚持使用 KeyCloak（您可以将其视为具有您想要的分散式网关的无头 API 管理系统）。
免责声明：我对 KeyCloak 的了解有些过时；可能有更新也进入 API 门户方向，但我不知道。
于 2019-04-08T15:40:41.933 回答