API 生命周期管理中的一个重要部分是对 API 访问和流量路由执行细粒度控制。访问令牌已成为公认的 API 访问管理标准。基于 JSON Web Token (JWT) 的身份验证机制的优势之一是能够利用 JWT 中的声明来实现这种细粒度级别的访问控制。权限可编码为自定义声明，以供 API 所有者用于控制对其 API 的访问。在验证 JWT 后，API 代理便可将令牌中的所有字段获取为变量，并据此做出访问决策。
在上一篇博文中，我们探讨了 API Connectivity Manager 如何帮助运维人员和开发人员加强合作。在开发并增强 API 和服务体验时，拥有并运维 API 的不同业务线团队需要实施全面控制。
API Connectivity Manager 提供一系列策略，以供 API 所有者配置服务级设置，如 API 身份验证、授权及额外的安全防护要求。在本文中，我们将展示 API 所有者如何使用访问控制路由策略对特定路由实施细粒度控制，并对其进行进一步微调，以根据令牌中的特定声明执行每个 HTTP 方法和每个路由。
准备工作
您必须获取 F5 NGINX Management Suite 试用版或付费订阅 F5 NGINX Management Suite，其中包括 Instance Manager、API Connectivity Manager、NGINX Plus（作为 API 网关）及 NGINX App Protect（可保护 API）。申请 NGINX Management Suite 30 天免费试用版即可立即使用。
请参阅《安装指南》，了解如何安装 NGINX Management Suite 和 API Connectivity Manager。
授予对特定服务的访问权限并将流量路由至特定服务
假设我们发布了一个 Warehouse API 代理，其中包含库存、订单等多个端点。现在，我们希望推出一项名为 pricing 的新服务，但仅对少数已注册测试版的客户开放。此类客户可通过 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，betatester 声明设置为
false：
"sub": "user2@abc.com",
"betatester": false,现在，我们配置访问控制路由策略（access-control-routing），以便向 JWT 中包含值为 true 的 betatester 声明的用户授予对 pricing 服务的访问权限。
为简单起见，我们仅显示有效载荷策略。该策略仅适用于 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" : ""
}
}
]
}
]
}
基于请求头的路由
access-control-routing 策略的另一个用途是根据传入请求中的请求头值做出路由决策。API 所有者可以配置规则或条件，从而指定路由请求时必须匹配的请求头中的值。若请求包含请求头，则会被转发；若不包含请求头，则会被丢弃。
在本例中，仅在 version 请求头的值为 v1 时，请求才会被路由到 /seasons 端点。returnCode 值指定了当 version 请求头的值不是 v1 时返回的错误代码 — 本例中为 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 请求头的值并非 access-control-routing 策略所要求的 v1，因此该服务将返回状态码 403。
将多条规则添加到策略中
您可以将多条规则添加到 access-control-routing 策略中，以根据本文中介绍的一两个或三个条件（JWT 声明、有效方法及请求头值）来控制路由。请求必须符合所有规则中的条件才会进行路由，否则将被拦截。
总结
API Connectivity Manager 支持 API 所有者通过 API 级策略实施细粒度访问控制并做出动态路由决策，以控制其 API 和服务并增强体验。
申请 NGINX Management Suite 30 天免费试用版，即可开始使用 API Connectivity Manager。
