Manual Chapter :
API Protection: Use Cases
Applies To:
Show Versions![Show Versions](/etc/designs/pcx/techdocs/images/expandversions.gif)
BIG-IP APM
- 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
API Protection: Use Cases
API protection:
Validating JWT tokens for all API calls
In this example, the JWT access token is extracted and validated for all API
calls. When the JWT token is validated successfully, the API request is classified based on path
and method and assigned a specific API server.
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 protection profile, forAuthorization, useOAuth 2.0.
- On the Access Control tab, clickEditto see the visual representation of the per-request policy that was created.
- In the visual policy editor, edit the policy as needed for the API being protected.
Here is an example per-request policy configuration that validates JWT tokens for all API
requests.
![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase1.png/_jcr_content/renditions/original)
How it works
- Access Policy Manager receives an API request with an authorization header containing a JWT access token.
- The access token is extracted from the authorization header.
- For all API requests, the OAuth Scope agent validates the access token.
- If OAuth validation fails, an appropriate response object is selected based on the validation error. This response object can be overwritten by configuring an explicit Response Selection agent in the fallback branch, which encapsulates the HTTP status, header, and body information.
- When the Access token is successfully validated, the Request Classification agent classifies the API request based on the request path and method.
- Additional branch rules are applied to a path (GET /pet/findByStatus ()) for identifying valid status. An example branch expression that you can use is:
An appropriate response is returned for the API request if the branch expression fails.expr {[lsearch {available pending sold} [mcget {request.query.status}]] != -1} - For a specific path (GET /department ()), the API Server Selection agent chooses the appropriate API server to which to send the request.
API protection: Validating JWT tokens for specific API calls
In this example, the JWT access token is extracted and validated for
selected API calls. All incoming API requests are classified based on path and method.
The JWT access token is extracted and validated for requests with specific path IDs.
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 protection profile, forAuthorization, use no authorization.
- On the Access Control tab of the protection profile, forSSO Configuration, select an OAuth Bearer SSO configuration.
- On the Access Control tab, clickEditto see the visual representation of the per-request policy that was created.
- In the visual policy editor, edit the policy as needed for the API being protected.
Here is an example per-request policy configuration that validates JWT
tokens for a specific set of API requests.
![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase2.png/_jcr_content/renditions/original)
How it works
- Access Policy Manager receives an API request with an authorization header containing a JWT access token.
- The Request Classification agent classifies the API request based on its request path and method.
- For a specific path (POST /pet ()), the JWT access token is extracted from the authorization header.
- The OAuth Scope agent validates the access token.
- If OAuth validation fails, an appropriate response is returned for that API request. You need to configure the Response Selection agent to select the correct response object, which encapsulates HTTP status, header, and body information.
- On successful validation of the JWT access token, the API request is sent to the default API server associated with the API protection profile.
- For a specific path (GET /department ()), the API Server Selection agent chooses the appropriate API server to which to send the request.
- Additional branch rules are applied to another path (GET /pet/findByStatus ()) for identifying valid status. An example branch expression that you can use is:
An appropriate response is returned for the API request if the branch expression fails.expr { [ lsearch { available pending sold } [ mcget {request.query.status} ] ] != -1 }
API Protection: JWT SSO with Token Conversion
In this example, you assign an OAuth Bearer SSO configuration to the
API protection profile. The system generates a custom JWT token, and sends it as an
OAuth bearer token in the outgoing API request.
The per-request policy attached to the API protection profile extracts
the JWT access token from the authorization header in the API request. The OAuth scope
agent validates and sets subroutine variables. You can assign the OAuth bearer SSO
configuration to specific API request paths in the per-request policy. The OAuth bearer
SSO configuration generates a JWT access token using the claims configuration, and sends
it to the API server as an OAuth Bearer token.
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 protection profile, forAuthorization, useOAuth 2.0.
- On the Access Control tab of the protection profile, forSSO Configuration, select an OAuth Bearer SSO configuration that was previously created.
- On the Access Control tab, clickEditto see the visual representation of the per-request policy that was created.
- In the visual policy editor, edit the policy as needed for the API being protected.
You need to have created an OAuth Bearer SSO configuration (
). You associate it with the protection profile on the Access Control
tab.![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase3a.png/_jcr_content/renditions/original)
Here is an example OAuth Bearer SSO configuration for generating a new JWT
access token:
![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase3c.png)
You associate the OAuth Bearer SSO configuration on the Access Control tab of the API
protection profile.
![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase3a.png)
In the visual policy editor, select the OAuth bearer SSO configuration using
the SSO configuration agent in the per-request policy.
![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase3b.png)
Here is the example per-request policy configuration that converts a
JWT token to an OAuth Bearer token before sending it to the API server.
![](/content/dam/projects/techdocs/bigip-14-1-0/bigip/images/apiprotectusecase3.png)
How it works
- Access Policy Manager receives an API request with an authorization header containing a JWT access token.
- The access token is extracted from the authorization header.
- For all API requests, the OAuth Scope agent in the subroutine validates the access token.
- If OAuth validation fails, the system returns an appropriate response for that API request. You need to configure the Response Selection agent to select the correct response object, which encapsulates HTTP status, header, and body information.
- On successful validation of the JWT access token, the system applies an SSO configuration to all requests.
- The Request Classification agent classifies the API request based on its request path and method.
- For a specific path (GET /department ()), the API Server Selection agent chooses the appropriate API server to which to send the request. The system applies an OAuth bearer SSO configuration to generate a custom JWT access token for the selected API server.
- Additional branch rules are applied to another path (GET /pet/findByStatus ()) for identifying valid status. An example branch expression that you can use is:
If the branch expression fails, the system returns an appropriate response for the API request.expr { [ lsearch { available pending sold } [ mcget {request.query.status} ] ] != -1 }