API Gateway:パラメータベースのアクセス制御

---
#
# In this example, the request path of the API is `/{userId}/...
# JWT authentication is enabled for the API. Two claims, userId and userType, are available in the JWT.
# The following filter conditions apply:
# - If userType is set to admin, requests in all paths are allowed. 
# - If userType is set to user, only requests with the `/{userId}/...` path are allowed.
parameters:
  userId: "Token:userId"
  userType: "Token:userType"
  pathUserId: "path:userId"
#
# Rules are defined based on the preceding parameters. For each API request, the plug-in checks the rules in sequence. If a condition in a rule is met, the result is true and the action that is specified by ifTrue is performed. If a condition in a rule is not met, the result is false and the action that is specified by ifFalse is performed.
# The action ALLOW indicates that the request is allowed. The action DENY indicates that the request is denied and an error code is returned to the client. After the ALLOW or DENY action is performed, the plug-in does not check the remaining conditions. 
# If neither the ALLOW nor DENY action is performed, the plug-in proceeds to check the next condition.
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コンソールにログインします。 Open API> プラグインを選択します。 [カスタムデータセット] 、[データセットの作成] をクリックします。 タイプのPARAMETER_ACCESSを選択します。

データセットを作成したら、データセットIDをクリックしてデータエントリを表示および追加できます。 このデータセットを参照するパラメーターベースのアクセス制御プラグインは、データエントリを使用して要求をフィルタリングします。 データエントリの有効期間を設定することもできます。 データエントリは、有効期間が経過すると無効になる。

3.2. パラメータベースのアクセス制御プラグインのデータセットの構成

パラメーターベースのアクセス制御プラグインのデータセットを構成するには、assertParameterNameおよびassertInDatasetフィールドをパラメーターベースのアクセス制御プラグインの構成のrulesセクションに追加する必要があります。

• assertParameterName: プラグインがリクエストをフィルタリングするために使用するパラメーターの名前。 名前はparametersセクションで定義する必要があります。

• assertInDataset: データセットID。 assertParameterNameに指定されたパラメーターの値がデータセットに含まれているかどうかを確認します。

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

2つのフィールドは、conditionパラメーターと互換性があります。 ルールセクションで指定したルールごとに、assertParameterName + assertInDatasetペアまたは条件、またはその両方を指定できます。 両方が設定されている場合、条件のいずれかを満たす場合、要求は拒否されます。

---
#
# In this example, the request path of the API is `/{userId}/...
# JWT authentication is enabled for the API. Two claims, userId and userType, are available in the JWT.
# The following filter conditions apply:
# - If userType is set to admin, requests in all paths are allowed. 
# - If userType is set to user, only requests with the `/{userId}/...` path are allowed.
parameters:
  userId: "Token:userId"
  userType: "Token:userType"
  pathUserId: "path:userId"
#
# Rules are defined based on the preceding parameters. For each API request, the plug-in checks the rules in sequence. If a condition in a rule is met, the result is true and the action that is specified by ifTrue is performed. If a condition in a rule is not met, the result is false and the action that is specified by ifFalse is performed.
# The action ALLOW indicates that the request is allowed. The action DENY indicates that the request is denied and an error code is returned to the client. After the ALLOW or DENY action is performed, the plug-in does not check the remaining conditions. 
# If neither the ALLOW nor DENY action is performed, the plug-in proceeds to check the next condition.
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>