API Connectivity Managerで詳細なアクセス制御とルーティングを適用

NGINX | 2023年1月12日

APIのライフサイクル全体を管理するうえで重要なのが、APIへのアクセスとトラフィックルーティングをきめ細かく制御することです。アクセストークンは、APIへのアクセスを管理する事実上の標準となっています。JSON Web Token（JWT）に基づく認証方式の利点の1つは、JWT内のクレームを活用して、このようなきめ細かなアクセス制御を実装できることです。権限はカスタムクレームとしてエンコードでき、API所有者はそれを使用して自身のAPIへのアクセスを制御できます。APIプロキシがJWTを検証すると、トークン内のすべてのフィールドを変数として参照し、それらに基づいてアクセスを許可するかどうかを判断できます。

In a 以前の記事では、API Connectivity Managerが運用担当者と開発者の連携強化にどのように役立つかを説明しました。APIを所有・運用する各事業部門のチームには、APIやサービスのエクスペリエンスを開発・向上させるうえで、全面的な管理権限が必要です。

API Connectivity Managerは、APIの認証、認可、追加のセキュリティ要件など、サービスレベルの設定をAPI所有者が構成できるポリシーを提供します。本記事では、API所有者がAccess Control Routingポリシーを使用して特定のルートにきめ細かな制御を適用し、さらにトークン内の特定のクレームに基づいてHTTPメソッドおよびルートごとに適用できるよう調整する方法を紹介します。

前提条件

APIゲートウェイとしてのNGINX Plusと、APIを保護するNGINX App Protectに加え、Instance ManagerとAPI Connectivity Managerを含むF5 NGINX Management Suiteのトライアルサブスクリプションまたは有料サブスクリプションが必要です。利用を開始するには、NGINX Management Suiteの30日間無料トライアルをお申し込みください。

NGINX Management SuiteとAPI Connectivity Managerのインストール手順については、「インストールガイド」を参照してください。

特定のサービスへのアクセス許可とトラフィックのルーティング

たとえば、倉庫APIプロキシを公開し、inventory、ordersなどの複数のエンドポイントを提供しているとします。ここで、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,

次に、JWTに値がtrueのbetatesterクレームが含まれるユーザーにpricingサービスへのアクセスを許可するよう、Access Control Routingポリシー（access-control-routing）を設定します。

簡潔にするため、ポリシーのペイロードのみを示します。このポリシーは、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所有者は、リクエストをルーティングするために一致が必要なヘッダー値を指定するルールまたは条件を設定できます。該当するヘッダーを含むリクエストは転送され、含まないリクエストは破棄されます。

この例では、リクエストヘッダー/seasonsの値がversion request header has value v1の場合にのみ、リクエストが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ヘッダーの値がv1ではないため、サービスはステータスコード403を返します。

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

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