api网关后面的keycloak是一个好习惯吗？答案

【问题标题】：Is keycloak behind api gateway a good practice?api网关后面的keycloak是一个好习惯吗？
【发布时间】：2018-08-09 22:26:59
【问题描述】：

支持在 Api 网关 (Kong) 后面使用或不使用 Keycloak 有哪些好的论据？

【问题讨论】：

标签： keycloak kong

【解决方案1】：

将其置于代理之后需要权衡：您将无法通过在全局级别应用 OIDC 插件来轻松保护所有服务。相反，您需要使用自己的 OIDC 插件单独配置每个服务。这是因为您将需要至少一项不受 OIDC 插件保护的服务，以便用户代理可以通过该服务进行身份验证。除非您打算在该服务上实现某种其他形式的安全性，或者需要在请求通过它时 Kong 可以轻松实现的其他服务，否则我认为将 Keycloak 放在代理后面没有意义。这并不是说没有充分的理由这样做，我只是不知道。

我已经在代理之外设置了 Keycloak，并且取得了不错的效果。这是它的样子：

我现在正在写一篇关于这个设置的博文，我将在下周发布。完成后，我会尽量记住在此处更新我的答案。

编辑

博客链接： Part 1, Part 2

【讨论】：

我猜你现在可以用你博客的链接更新这篇文章了？ :)
我还看到一些公司将像 Kong 这样的反向代理放在 DMZ 中，如果这对任何人都有帮助的话。

【解决方案2】：

这不是一个好的做法，事实上我建议把它放在外面，在 DMZ 中。通过这种方式，您希望使用 API 网关发布和验证的所有 API 都可以利用 IDP。这是使用 Keycloak 应用此类身份验证流程的示例：https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss

您可能会担心：如何保护像 IDP 这样的关键资源来验证我的所有服务？您可以通过以下方式解决的合理问题：

确保根据身份验证请求自动扩展 IDP
在 Keycloak (https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks) 上配置所有需要的威胁缓解选项
在 IDP 前添加 WAF，具有 DDOS 预防和基于流量模式的智能威胁缓解等功能
IP 或域白名单（如果您知道所有客户的连接来源）
限制 IDP 的端口暴露

【讨论】：

【解决方案3】：

Kong 是一个 API 网关，它将位于“热路径”中 - 在每个 API 请求的请求和响应周期中。 Kong 擅长以极低的延迟有效地代理大量请求。

Keycloak 和其他 IAM 产品可以与 Kong 集成 - 但它们并未置于热门路径中。 Keycloak 擅长管理用户和权限，并在需要时将这些信息提供给 Kong 等系统。

也许这些链接会有所帮助https://github.com/ncarlier/kong-integration-samples 和 https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html

【讨论】：

【解决方案4】：

不是一个好的做法，一个好的企业 API 网关有义务满足（或允许您自定义）KEYCLOAK 中提供的所有高级身份验证和授权标准。

但在某些情况下，如果您已经有一个配置了很多 API 的 API 网关（带有转换规则、路由规则），并且该网关无法提供用于身份验证和授权的高级功能（例如 2 因素身份验证或Oauth2 授权码/openId / SAML），您需要尽快提高安全性，继续寻找最能满足您需求的网关

【讨论】：

我理解 Keycloack / Gluu / Okta 之类的服务无论如何都需要，唯一的问题是是在 api 网关后面使用还是在 api 网关旁边使用。从未听说过将所有东西都放在一个包中的网关，我认为这不是一件好事。让我知道你认为我哪里错了。
Keycloak 是一个 IAM 套件，可以在不同的场景（API Gateway 后、侧、前）中扮演不同的角色。你能描述一下你的架构吗？ FIY：IAM 套件中的许多身份验证和授权功能已经被其他类型的工具合并，例如 API 管理工具（例如 Axway、Apigee 或 CA 第 7 层），其中不需要 Keycloak 或 otka，因为它易于操作多个身份提供者并通过策略创建 API 和 IAM 流并保护资源。
Kong (Mashape) 实际上就像 Apigee 或 Axway。所以我仍然需要一些 IAM。建筑是我不确定的东西。基本上最初用户未经过身份验证，因此某些路由无法通过 Kong 访问。所以在用户需要通过 Keycloak 进行身份验证之后。我不知道在哪里保留 Keycloak 服务，在 Kong （开放路线）之后或作为一个单独的服务，没有 Kong 代理。我的假设是把它放在 Proxy 后面是一个更好的解决方案。