使用API Connectivity Manager实施精细化访问控制和路由

NGINX | 2023年1月12日

在API的整个生命周期中进行管理时,对API访问和流量路由实施精细控制至关重要。访问令牌已成为管理API访问的事实标准。基于JSON Web Token(JWT)的身份验证方案有一项优势,即可以利用JWT中的声明来实现这种精细的访问控制。权限可以编码为自定义声明,API所有者可借此控制对其API的访问。API代理验证JWT后,即可将令牌中的所有字段作为变量使用,并据此做出访问决策。

在上一篇文章中,我们探讨了API Connectivity Manager如何帮助运维人员与开发人员更好地协作。来自不同业务线、负责API所有权和运营的团队,需要在开发和优化API及服务体验时拥有完全控制权。

API Connectivity Manager提供相关策略,使API所有者能够配置服务级设置,例如API身份验证、授权和其他安全要求。本文将介绍API所有者如何使用Access Control Routing策略对特定路由实施精细控制,并根据令牌中的特定声明进一步调整,使其按HTTP方法和路由应用。

先决条件

必须拥有F5 NGINX Management Suite的试用版或付费订阅。该套件包括Instance Manager和API Connectivity Manager,并提供用作API网关的NGINX Plus以及用于保护API的NGINX App Protect。要开始使用,请申请NGINX Management Suite的30天免费试用版。

有关如何安装NGINX Management Suite和API Connectivity Manager的说明,请参阅《安装指南》。

授予访问权限并将流量路由到特定服务

假设我们已发布一个仓库API代理,其中包含多个端点,例如inventory、orders等。现在,我们希望引入一项名为pricing的新服务,但仅允许少数已注册参加Beta试用的客户端访问。此类客户端通过名为betatester的声明进行标识。在此示例访问令牌中,对于由sub声明标识的用户user1@abc.com,该声明的值为true。

Header
{
  "kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
  "alg": "RS256"
}
Payload

{
  "ver": 1,
  "jti": "AT.xxxxxxxxxxxx",
  "iss": "https://oauthserver/oauth2/", "aud": "inventoryAPI", "iat": 1670290877, "exp": 1670294477, "cid": "AcvfDzzzzzzzzz", "uid": "yyyyyyyWPXulqE4x6", "scp": [ "apigw" ], "auth_time": 1670286138, "sub": "user1@abc.com", "betatester": true, "domain": "abc" }

对于user2@abc.com,由于未入选Beta测试计划,其betatester声明被设置为
false:

"sub": "user2@abc.com","betatester": false,

现在,我们配置访问控制路由策略(access-control-routing),为JWT中包含值为pricing的betatester声明且该值为true的用户授予访问权限。

为简洁起见,此处仅显示策略有效负载。此策略仅适用于API Connectivity Manager中基于令牌的策略,例如JWT Assertion和OAuth2 Introspection。

"policies": {  "access-control-routing": [
    {
      "action": {
        "conditions": [
          {
            "allowAccess": {
              "uri": "/pricing"
            },
            "when": [
              {
                "key": "token.betatester",
                  "matchOneOf": {
                    "values": [
                      "true"
                    ]
                  }
              }
            ]
          }
        ],
        "returnCode": 403
      }
    }
  ]
}

应用该策略后,API代理会验证已认证用户的JWT声明,并实施细粒度访问控制,以路由来自user1@abc.com的请求,同时拒绝来自user2@abc.com的请求。

控制特定方法的使用

我们可以进一步微调access-control-routing策略,以控制哪些用户可以使用特定的HTTP方法。在本例中,API代理仅允许管理员(令牌中包含值Admin的用户)使用DELETE方法。

"policies":{  "access-control-routing":[
    "action":{
      "conditions":[
        {
          "when":[
            {
              "key":"token.{claims}",
              "matchOneOf":{
                "values":[
                  "Admin"
                ]
              }
            }
          ],
          "allowAccess":{
            "uri":"/v1/customer",
            "httpMethods":[
              "DELETE"
            ]
          },
          "routeTo" : {
            "targetBackendLabel" : ""
          }
        }
      ]
    }
  ]
}

基于标头的路由

访问控制路由策略的另一种用途是根据传入请求中的标头值作出路由决策。API所有者可以配置规则或条件,指定请求必须匹配的标头值,才能进行路由。包含该标头的请求将被转发,否则将被丢弃。

In this example, a request is routed to the /seasons endpoint only when the version request header has value v1. The returnCode value specifies the error code to return when version is not v1 – in this case, it’s 403 (Forbidden).

"access-control-routing": [  {
    "action": {
      "conditions": [
        {
          "allowAccess": {
            "uri": "/seasons"
          },
          "when": [
            {
              "key": "header.version",
              "matchOneOf": {
                "values": [
                  "v1"
                ]
              }
            }
          ]
        }
      ],
      "returnCode": 403
    }
  }
]

在此示例curl请求中,我们向seasons服务发送请求,并将version标头设置为v2:

curl -H "version: v2" http://example.com/seasons

由于version标头的值不是策略要求的v1,服务返回状态代码403。

在策略中包含多条规则

可以在访问控制路由策略中包含多条规则,根据本文讨论的一项、两项或全部三项条件来控制路由:JWT声明、有效方法和请求标头值。请求必须满足所有规则中的条件才能被路由,否则将被阻止。

总结

API Connectivity Manager支持API所有者通过API级策略控制并优化API和服务的使用体验。这些策略可实施精细化访问控制,并动态作出路由决策。

要开始使用API Connectivity Manager,请申请NGINX Management Suite的30天免费试用。


分享
标签: F5 NGINX, Tech

相关博客文章

NGINX Plus R26 正式发布
NGINX | 2022/02/15

NGINX Plus R26 正式发布

NGINX Plus R26通过缓存JSON Web密钥集加快JWT验证,并强化TLS握手,从而提升安全性。NGINX JavaScript的新功能包括增强对异步函数的支持,以及实现WebCrypto API。

使用NGINX App Protect DoS保护gRPC应用,抵御严重的DoS攻击
NGINX | 2022/02/10

使用NGINX App Protect DoS保护gRPC应用,抵御严重的DoS攻击

gRPC具备开发人员设计和部署现代应用所需的速度与灵活性,但其开放性也使其极易受到第7层DoS攻击。NGINX App Protect DoS可保护gRPC应用免受此类破坏性攻击。

Ingress Controller 选型指南(第 2 部分):风险与面向未来的规划
NGINX | 2021/09/13

Ingress Controller 选型指南(第 2 部分):风险与面向未来的规划

了解选择错误的Ingress控制器可能带来的风险,以及如何从关键方面着手,让您的选择更好地适应未来需求。

NGINX Plus R19 正式发布
NGINX | 2019/09/03

NGINX Plus R19 正式发布

NGINX Plus R19扩展了监控功能,不仅提供更多指标,还新增了指标分析方式;增加试运行模式,用于测试限速效果;增强键值存储,以支持IP地址范围;并使限速更加动态。

NGINX现已正式加入F5
NGINX | 2019/05/09

NGINX现已正式加入F5

NGINX现已正式成为F5的一部分。Gus Robertson现任F5 NGINX业务部门负责人。他阐述了两家公司在人才、文化和愿景方面融合的价值,以及双方将如何携手增强NGINX的开源产品和商业产品。

使用NGINX和NGINX Plus实现高性能缓存
NGINX | 2016/08/24

使用NGINX和NGINX Plus实现高性能缓存

我将介绍NGINX在内容缓存和性能方面的工作原理,并分享一些控制NGINX内容缓存方式的技巧。