PingIntelligence

NGINX Plus sideband integration

This guide describes the deployment of PingIntelligence for APIs in a sideband configuration with NGINX Plus.

A PingIntelligence sideband policy is installed in NGINX Plus and passes API metadata to PingIntelligence for detailed API activity reporting and attack detection with optional client blocking. PingIntelligence software adds support for reporting and attack detection based on usernames captured from token attributes.

Traffic flow for NGINX Plus integration with user information

Traffic flow for NGINX Plus integration without user information

Here is the traffic flow through NGINX and PingIntelligence for APIs components.

A diagram of the PingIntelligence and NGINX integration traffic flow.

  1. Client sends an incoming request to NGINX.

  2. NGINX makes an API call to send the request metadata to ASE.

  3. ASE checks the request against a registered set of APIs and looks for the origin IP, cookie, OAuth2 token, or API key in PingIntelligence AI engine generated Blacklist. If all checks pass, ASE returns a 200-OK response to the NGINX. If not, a different response code is sent to NGINX. The request information is also logged by ASE and sent to the AI engine for processing.

  4. If NGINX receives a 200-OK response from ASE, then it forwards the request to the backend server. Otherwise, NGINX optionally blocks the client.

  5. The response from the backend server is received by NGINX.

  6. NGINX makes a second API call to pass the response information to ASE which sends the information to the AI engine for processing.

  7. ASE receives the response information and sends a 200-OK to NGINX.

  8. NGINX sends the response received from the backend server to the client.

Traffic flow for NGINX Plus integration with user information

Below is the traffic flow through the NGINX Plus and PingIntelligence for APIs components. PingFederate is used as the OAuth server to gather the user information:

A diagram of the PingIntelligence and NGINX Plus integration traffic flow.

  1. The client requests and receives an access token from PingFederate.

  2. The client sends a request with the access token received from PingFederate.

  3. NGINX Plus verifies the authenticity of the access token with PingFederate.

  4. If the request is invalid, ASE sends a 403 error, and NGINX Plus drops the connection request.

  5. If the token is valid, the PingIntelligence policy running in NGINX Plus collects API metadata and token attributes. In case of an invalid token, the request is allowed, however, without user information.

  6. NGINX Plus makes an API call to send the request information to ASE. ASE checks the request against a registered set of APIs and checks the origin IP, cookie, or OAuth2 token against the AI-generated deny list. If all checks pass, ASE returns a 200-OK response to the NGINX Plus. If not, a different response code is sent to NGINX Plus. The request information is also logged by ASE and sent to the AI engine for processing.

  7. If NGINX Plus receives a 200-OK response from ASE, then it forwards the request to the backend server. Otherwise, the Gateway optionally blocks the client.

  8. The response from the backend server is received by NGINX Plus. NGINX Plus sends the response received from the backend server to the client.

  9. NGINX Plus makes a second API call to pass the response information to ASE, which sends the information to the AI engine for processing. ASE receives the response information and sends a 200-OK to NGINX Plus.

  10. NGINX Plus sends the response to the client.