API Gateway:パラメーターベースのアクセスコントロールプラグイン

---
#
# この例では、API リクエストパスが `/{userId}/...` であることを前提としています
# API は JWT 認証を使用し、トークンには `userId` と `userType` のクレームが含まれています。
# プラグインは、次の条件に基づいてリクエストを検証します：
# - userType が 'admin' の場合、すべてのパスが許可されます。
# - userType が 'user' の場合、パスの `userId` がトークンの `userId` と一致するリクエストのみが許可されます。
parameters:
  userId: "Token:userId"
  userType: "Token:userType"
  pathUserId: "path:userId"
#
# プラグインはルールを順番に処理します。各ルールについて、条件を評価します。
# 条件が `true` を返した場合、プラグインは `ifTrue` アクションを実行します。`false` の場合は `ifFalse` アクションを実行します。
# `ALLOW` はリクエストを即座に許可します。`DENY` はリクエストを即座に拒否し、クライアントにエラーを返します。
# `ALLOW` も `DENY` もトリガーされない場合、プラグインは次のルールに進みます。
rules:
  - name: admin
    condition: "$userType = 'admin'"
    ifTrue: "ALLOW"
  - name: user
    condition: "$userId = $pathUserId"
    ifFalse: "DENY"
    statusCode: 403
    errorMessage: "Path not match ${userId} vs /${pathUserId}"
    responseHeaders:
      Content-Type: application/xml
    responseBody: 
      <Reason>Path not match ${userId} vs /${pathUserId}</Reason>

3. プラグインデータセット

詳細な説明と設定手順については、「パラメーターベースのアクセスコントロールプラグイン」をご参照ください。

3.1. プラグインデータセットの作成

API Gateway コンソールにログインします。左側のナビゲーションウィンドウで、API の管理 > プラグイン を選択します。[プラグインデータセット] タブに移動し、[データセットの作成] をクリックして、データセットタイプとして PARAMETER_ACCESS を選択します。

その後、データセット ID をクリックしてデータ入力を表示できます。[データ入力の作成] をクリックして、新しいデータ入力を追加します。[データ値] は、アクセスの制御に使用されるパラメーター値に対応します。各データ入力に有効期限を設定することもできます。データ入力は有効期限が切れると無効になります。

[データ入力の作成] ダイアログボックスの [有効期限] では、[短期] (特定の日付を選択) または [長期] (有効期限なし) を選択できます。また、[説明] を入力することもできます。

3.2. プラグインデータセットの設定

プラグインデータセットを使用するには、パラメーターベースのアクセスコントロールプラグイン設定の rules セクションのルールに assertParameterName および assertInDataset フィールドを追加します。

• assertParameterName：データセットに対して検証するパラメーターの名前。このパラメーターは parameters セクションで定義する必要があります。

• assertInDataset：プラグインデータセットの ID。プラグインは、assertParameterName で指定されたパラメーターの値がこのデータセットに存在するかどうかをチェックします。

assertParameterName フィールドと assertInDataset フィールドは一緒に使用する必要があります。そうしない場合、プラグインの作成は失敗します。

これらのフィールドは condition フィールドと互換性があります。各 rule 内で、(assertParameterName, assertInDataset) のペアと condition の両方、またはいずれか一方を設定できます。両方が設定されている場合、データセットのチェックに合格するか、条件式が true と評価されると、プラグインはルールのアクションをトリガーします。

---
#
# この例では、API リクエストパスが `/{userId}/...` であることを前提としています
# API は JWT 認証を使用し、トークンには `userId` と `userType` のクレームが含まれています。
# プラグインは、次の条件に基づいてリクエストを検証します：
# - userType が 'admin' の場合、すべてのパスが許可されます。
# - userType が 'user' の場合、パスの `userId` がトークンの `userId` と一致するリクエストのみが許可されます。
parameters:
  userId: "Token:userId"
  userType: "Token:userType"
  pathUserId: "path:userId"
#
# プラグインはルールを順番に処理します。各ルールについて、条件を評価します。
# 条件が `true` を返した場合、プラグインは `ifTrue` アクションを実行します。`false` の場合は `ifFalse` アクションを実行します。
# `ALLOW` はリクエストを即座に許可します。`DENY` はリクエストを即座に拒否し、クライアントにエラーを返します。
# `ALLOW` も `DENY` もトリガーされない場合、プラグインは次のルールに進みます。
rules:
  - name: byDataset
    assertParameterName: userId
    assertInDataset: 87b65008e92541938537b1a4a236eda5
    ifTrue: "ALLOW"
  - name: admin
    condition: "$userType = 'admin'"
    ifTrue: "ALLOW"
  - name: user
    condition: "$userId = $pathUserId"
    ifFalse: "DENY"
    statusCode: 403
    errorMessage: "Path not match ${userId} vs /${pathUserId}"
    responseHeaders:
      Content-Type: application/xml
    responseBody: 
      <Reason>Path not match ${userId} vs /${pathUserId}</Reason>