在整个生命周期中管理 API 的一个重要部分是对 API 访问和流量路由进行细粒度的控制。 访问令牌已成为管理 API 访问的事实标准。 基于 JSON Web Tokens(JWT)的身份验证方案的优势之一是能够利用 JWT 中的声明来实现精细的访问控制。 权限可以编码为自定义声明,API 所有者可以使用它来控制对其 API 的访问。 一旦 API 代理验证了 JWT,它就可以将令牌中的所有字段作为变量进行访问,并可以基于它们做出访问决策。
在之前的文章中,我们讨论了 API Connectivity Manager 如何帮助运营商和开发人员更好地合作。 拥有和运营 API 的不同业务线的团队在开发和增强其 API 和服务体验时需要完全控制。
API 连接管理器提供的策略使 API 所有者能够配置服务级别设置,如 API 身份验证、授权和其他安全要求。 在这篇文章中,我们展示了 API 所有者如何使用访问控制路由策略对特定路由实施细粒度控制,并根据令牌中的特定声明进一步对其进行微调以应用于每个 HTTP 方法和每个路由。
您必须拥有F5 NGINX 管理套件的试用版或付费订阅,其中包括实例管理器和 API 连接管理器以及作为 API 网关的 NGINX Plus 和用于保护您的 API 的 NGINX App Protect。 首先,申请NGINX 管理套件的 30 天免费试用版。
有关如何安装 NGINX 管理套件和 API 连接管理器的说明,请参阅安装指南。
假设我们已经发布了一个仓库 API 代理,它有多个端点,例如库存、订单等等。 现在,我们想推出一项名为定价的新服务,但只有少数已注册 Beta 试用版的客户才能使用它。 此类客户可通过名为betatester
的声明来识别。 在此示例访问令牌中,该声明对于sub
声明中标识的用户user1@abc.com
来说是正确的
。
标题
{
“kid”: “123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx”,
“alg”: “RS256”
}
有效载荷
{
“ver”: 1,
“jti”: “AT.xxxxxxxxxxxx”,
“iss”:“https://oauthserver/oauth2/”,
“aud”:“inventoryAPI”,
“iat”: 1670290877,
“表达式”: 1670294477,
“cid”: “AcvfDzzzzzzzzzz”,
“uid”:“yyyyyyyWPXulqE4x6”,
“scp”: [
“apigw”
],
“auth_time”: 1670286138,
“sub”:“user1@abc.com”,
“betatester”:true,
“domain”:“abc”
}
对于未被选入 beta 计划的user2@abc.com
, betatester
声明设置为
错误的:
“sub”:“user2@abc.com”,“betatester”:false,
现在我们配置访问控制路由策略 ( access-control-routing ),以向 JWT 包含betatester
声明且值为true
的用户授予定价服务的访问权限。
为了简洁起见,我们仅显示策略有效负载。 此策略仅适用于 API 连接管理器中基于令牌的策略,例如 JWT 断言和 OAuth2 Introspection。
“策略”:{“访问控制路由”:[
{
“操作”:{
“条件”:[
{
“allowAccess”:{
“uri”:“/pricing”
},
“何时”:[
{
“key”:“token.betatester”,
“matchOneOf”:{
“值”:[
“true”
]
}
}
]
}
],
“returnCode”: 403
}
}
]
}
一旦我们应用该策略,API 代理就会为经过身份验证的用户验证 JWT 中的声明,执行细粒度的访问控制以路由来自user1@abc.com 的
请求并拒绝来自user2@abc.com
的请求。
我们可以进一步微调访问控制路由策略来控制哪些用户可以使用特定的 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 所有者可以配置规则或条件,指定要路由的请求必须匹配的标头中的值。 如果请求包含标头,则转发请求,如果不包含,则丢弃请求。
在此示例中,仅当版本
请求标头具有值v1
时,请求才会路由到/seasons端点。 returnCode
值指定当版本
不是v1
时返回的错误代码 - 在本例中为403
(禁忌)
“访问控制路由”:[{
“操作”:{
“条件”:[
{
“allowAccess”:{
“uri”:“/seasons”
},
“何时”:[
{
“key”:“header.version”,
“matchOneOf”:{
“值”:[
“v1”
]
}
}
]
}
],
“returnCode”: 403
}
}
]
在此示例curl
请求中,我们向季节服务发送一个请求,并将版本
标头设置为v2
:
curl -H “版本:v2” http://example.com/seasons
由于版本
头的值不是策略要求的v1
,服务返回状态码403
。
您可以在访问控制路由策略中包含多个规则,以根据本文讨论的一个、两个或全部三个标准来控制路由: JWT 声明、有效方法和请求标头值。 请求必须符合所有规则中的条件才能被路由;否则,它将被阻止。
API 连接管理器使 API 所有者能够通过应用细粒度访问控制和做出动态路由决策的 API 级策略来控制和增强其 API 和服务体验。
要开始使用 API 连接管理器,请申请NGINX 管理套件的 30 天免费试用版。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”