Kong认证

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

前言

上游服务（代理的API或微服务）的流量通常由各种Kong身份验证插件的应用程序和配置控制。 Kong的service概念与上游服务是一对一映射，因此可以通过在service上配置认证插件来控制访问上游服务的权限。

核心概念

  • service：上游服务的抽象，与上游服务是一对一映射， 比如后端微服务，API等。

  • consumer：消费者的核心原则是您可以将插件附加到他们，从而自定义请求行为，消费者可以代表一个用户，一个应用程序等。

通用认证

最常见的情况是要求进行身份验证，并且不允许访问任何未经身份验证的请求。 为此，可以使用任何身份验证插件。 这些插件的通用方案/流程如下：

  1. 将认证插件应用到service，或全局应用。

  2. 创建一个consumer。

  3. 为consumer配置凭据。

  4. 有任何请求进入，Kong都会检查提供的凭据（取决于身份验证类型），并且如果无法验证将阻止该请求。

匿名访问

Kong可以配置给定服务同时允许身份验证和匿名访问。一种可能的应用场景是，允许低频访问的匿名，而高频访问的必须验证。因此所有的认证插件都有一个config.anonymous的配置。

要实现匿名访问，首先要创建一个不添加任何凭据的consumer，然后添加一个认证插件，设置认证插件的config.anonymous为consumer的id。以Key认证为例，当在service启用key认证时，必须携带配置好的key name参数及consumer配置好的有效凭据，例如：http://localhost/mockauth?apikey=open_sesame，但如果配置了config.anonymous，则可以不携带，直接访问http://localhost/mockauth，匿名访问与Key认证是逻辑或的关系，满足之一即可。

多重认证

要理解多重认证，首先要理解上面的匿名访问逻辑。

Kong支持给定服务的多个身份验证插件，从而允许不同的客户端使用不同的身份认证方式，来访问给定的服务或路由。这些插件在执行验证行为时，可以有AND，OR的关系，也就是说可以自由配置是满足所有验证还是满足其中一个或几个。验证行为的逻辑关键在于config.anonymous的配置。

  • 如果未设置config.anonymous，认证插件将始终执行验证。

  • 如果设置了config.anonymous，将允许匿名访问，认证插件将仅在尚未通过身份验证的情况下执行身份验证。

假设某service同时安装key-auth，basic-auth插件（以下简称A，B），并且都启用的情况下：

  1. 若 A，B都没有设置config.anonymous，则逻辑关系为A and B，A和B必须同时认证成功。

  2. 若A设置config.anonymous，B没有，则逻辑关系为（A or 匿名）and B，B认证成功或A，B同时认证成功。

  3. 若A，B都设置了config.anonymous，则逻辑关系为（A or 匿名）and (B or 匿名)，可以匿名访问。

  4. 若A，B都设置了config.anonymous，同时采用request-termination 禁止匿名访问，则逻辑关系为A or B ，A或者B认证成功即可。

以上是 Kong认证 的全部内容， 来源链接： utcz.com/z/516331.html

回到顶部