Kong认证

编程

前言

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

核心概念

  • service:上游服务的抽象,与上游服务是一对一映射, 比如后端微服务,API等。
  • consumer:消费者的核心原则是您可以将插件附加到他们,从而自定义请求行为,消费者可以代表一个用户,一个应用程序等。

通用认证

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

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

  2. 创建一个consumer

  3. consumer配置凭据。

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

匿名访问

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

要实现匿名访问,首先要创建一个不添加任何凭据的consumer,然后添加一个认证插件,设置认证插件的config.anonymousconsumer的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

回到顶部