API 接続マネージャーによるきめ細かなアクセス制御とルーティングの適用

API をライフサイクル全体にわたって管理する上で重要なのは、API アクセスとトラフィック ルーティングをきめ細かく制御することです。 アクセス トークンは、API へのアクセスを管理するための事実上の標準として登場しました。 JSON Web Token (JWT) に基づく認証スキームの利点の 1 つは、JWT 内のクレームを活用して、きめ細かいレベルのアクセス制御を実装できることです。 権限はカスタムクレームとしてエンコードすることができ、API 所有者はこれを使用して API へのアクセスを制御できます。 API プロキシが JWT を検証すると、トークン内のすべてのフィールドに変数としてアクセスできるようになり、それらに基づいてアクセスの決定を行うことができます。

前回の投稿では、API Connectivity Manager がオペレーターと開発者の連携にどのように役立つかについて説明しました。 API を所有および運用するさまざまな事業部門のチームは、API とサービスのエクスペリエンスを開発および強化する際に完全な制御を必要とします。

API Connectivity Manager は、 API 所有者が API 認証、承認、追加のセキュリティ要件などのサービス レベルの設定を構成できるようにするポリシーを提供します。 この投稿では、API 所有者がアクセス制御ルーティングポリシーを使用して特定のルートに対してきめ細かい制御を適用し、トークン内の特定のクレームに基づいて 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 をインストールする方法については、インストール ガイドを参照してください。

特定のサービスへのアクセスを許可し、トラフィックをルーティングする

inventory 、 ordersなどの複数のエンドポイントを持つ倉庫 API プロキシを公開したとします。 ここで、 Pricingという新しいサービスを導入し、ベータ版トライアルにサインアップした少数のクライアントのみがアクセスできるようにしたいと考えています。 このようなクライアントは、 betatesterと呼ばれるクレームによって識別されます。 このサンプル アクセス トークンでは、そのクレームはサブクレームで識別されるユーザーuser1@abc.comに対してtrueです。

ヘッダー
{
「子供」: "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
"alg": "RS256"
}
ペイロード

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

ベータプログラムに選ばれなかったuser2@abc.comの場合、 betatesterクレームは次のように設定されます。
間違い：

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

ここで、アクセス制御ルーティング ポリシー ( access-control-routing ) を構成して、JWT に値がtrueのbetatesterクレームが含まれているユーザーに価格設定サービスへのアクセスを許可します。

簡潔にするために、ポリシー ペイロードのみを示します。 このポリシーは、JWT アサーションや OAuth2 イントロスペクションなど、API Connectivity Manager のトークンベースのポリシーでのみ機能します。

"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からのリクエストを拒否します。

特定の方法の使用を制御する

アクセス制御ルーティングポリシーをさらに微調整して、特定の 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" : ""
}
}
]
}
]
}

ヘッダーベースのルーティング

アクセス制御ルーティングポリシーのもう 1 つの用途は、受信リクエストのヘッダー値に基づいてルーティングの決定を行うことです。 API 所有者は、リクエストをルーティングするために一致する必要があるヘッダー内の値を指定するルールまたは条件を設定できます。 リクエストは、ヘッダーが含まれている場合は転送され、含まれていない場合はドロップされます。

この例では、バージョンリクエスト ヘッダーの値がv1 の場合にのみ、リクエストが/seasonsエンドポイントにルーティングされます。 の 戻りコード 値は、返されるエラーコードを指定します。 バージョン ではない v1 - この場合、 その 403 （禁断）。

"アクセス制御ルーティング": [ {
"アクション": {
"条件": [
{
"allowAccess": {
"uri": "/seasons"
},
"when": [
{
"キー": "header.version",
"matchOneOf": {
"値": [
"v1"
]
}
}
]
}
],
"戻りコード": 403
}
}
]

このサンプルcurlリクエストでは、バージョンヘッダーをv2に設定して、 seasonsサービスにリクエストを送信します。

curl -H "バージョン: v2" http://example.com/seasons

バージョンヘッダーの値がポリシーで要求されているv1ではないため、サービスはステータスコードを返します。403 。

ポリシーに複数のルールを含める

アクセス制御ルーティングポリシーに複数のルールを含めて、この記事で説明した 1 つ、2 つ、または 3 つの基準すべてに基づいてルーティングを制御できます。 JWT クレーム、有効なメソッド、およびリクエスト ヘッダー値。 リクエストがルーティングされるには、すべてのルールの条件に一致している必要があります。一致しない場合はブロックされます。

まとめ

API Connectivity Manager を使用すると、API 所有者は、きめ細かなアクセス制御を適用し、動的なルーティング決定を行う API レベルのポリシーを使用して、API とサービスのエクスペリエンスを制御および強化できます。

API Connectivity Manager を使い始めるには、 NGINX Management Suite の 30 日間無料トライアルをリクエストしてください。