Manual Chapter : API rate limiting: Quota enforcement with different weights

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 16.0.0
Manual Chapter

API rate limiting: Quota enforcement with different weights

In this example of API rate limiting, different API requests have different weights and therefore consume different quota numbers. The policy uses OAuth token validation, and branch logic is based on path and method.
  • GET requests have a lower weight (1)
  • POST requests have a heavier weight (2)
  • A POST by a salesperson to update the sales number gets a lower weight but a POST in which a user is posting a profile picture for an application gets heavier weight.
To develop this example, you need to
  • Create an API protection profile that defines the paths, servers, and responses preferably using an OpenAPI spec file.
  • In the API protection profile, for
    Authorization
    , use
    OAuth 2.0
    .
  • On the Rate Limiting tab of the API protection profile, create one rate limiting configuration that uses a request quota of 1000 requests every 5 minutes and spike arrest value of 200 for 1 minute.
  • You can use UserGroupID for the quota key and set the value to
    %{subsession.access_token.usergroup}
    .
  • On the Access Control tab, click
    Edit
    to see the visual representation of the per-request policy that was created.
  • In the visual policy editor, edit the policy as needed for rate limiting each branch. For the POST /profile/* branch, you can add an agent to check what group the user is in (sales or customer). The customer and sales branches can use the same rate limiting configuration but you can assign different weights (1 to sales and 2 to customers).
Here is the example API protection per-request policy that performs different levels of rate limiting for two airline applications.

How it works

  1. Access Policy Manager receives an API request with an authorization header containing a JWT access token.
  2. The access token is extracted from the authorization header.
  3. For all API requests, the OAuth Scope agent in the subroutine validates the access token.
  4. If OAuth validation fails, the system returns an appropriate response for that API request.
  5. On successful validation of the JWT access token, the policy classifies the API request based on the value of the request path and method, and sends it to the appropriate branch.
  6. For a specific branch (POST /profile/*), the branch expression classifies the request based on User Group
  7. Rate limiting is enforced differently for certain branches. For example, a salesperson updating sales numbers has a lower weight (1) assigned in the API Rate Limiting agent. (Sales requests add 1 to the quota.) But customers uploading profile photos are assigned a heavier weight because this activity consumes more resources. (Customer requests add 2 to the quota.)
  8. If the number of requests exceeds the quota, the system returns a response to the sender of the API request, and logs an error message.