API Gateway:Parameter-based access control

---
#
# 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. Use a plug-in dataset in a plug-in

For more information about how to configure a parameter-based access control plug-in, see Parameter-based access control.

3.1. Create a plug-in dataset

Log on to the API Gateway console. Choose Open API > Plug-ins. Click Custom Dataset and then Create Dataset. Select PARAMETER_ACCESS for Type.

After you create a dataset, you can click the dataset ID to view and add data entries. The parameter-based access control plug-in that references this dataset uses the data entries to filter requests. You can also set a validity period for a data entry. The data entry becomes ineffective when the validity period elapses.

3.2. Configure a dataset for a parameter-based access control plug-in

To configure a dataset for a parameter-based access control plug-in, you must add the assertParameterName and assertInDataset fields to the rules section of the configurations of the Parameter-based access control plug-in.

• assertParameterName: the name of the parameter to be used by the plug-in to filter requests. The name must be defined in the parameters section.

• assertInDataset: the dataset ID. The plug-in checks whether the value of the parameter specified in assertParameterName is included in the dataset.

The assertParameterName and assertInDataset fields must be used together. Otherwise, the plug-in fails to be created.

The two fields are compatible with the condition parameter. For each rule specified in the rules section, you can specify the assertParameterName + assertInDataset pair or condition, or both. If both are configured, a request is denied if it meets any of the conditions.

---
#
# 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>