api网关背后的关键斗篷是一个好习惯吗？

Question

赞成使用或不使用Api网关（Kong）背后的Keycloak有什么好的理由？

Answer 1

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

我已将Keycloak设置在代理之外，并取得了良好的效果。看起来是这样的：

我现在正在撰写有关此设置的博客文章，下周将发布。我会尽量记得在完成后在这里更新我的答案。

编辑

链接到博客： Part 1， Part 2

Answer 2

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很有帮助

Answer 3

这不是一个好习惯，实际上我建议将其放在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的端口暴露

Answer 4

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

但在某些情况下，如果您已经配置了许多API的API网关（具有转换规则，路由规则），并且此网关无法提供用于身份验证和授权的高级功能（例如，2因素身份验证或Oauth2授权代码/ openId / SAML）您需要更多安全性，在寻找最符合您需求的网关时继续进行